Silicon Valley Redneck

Yes, but not in the way you think.

Randomly spotted snippet from this article:

Outside the White House, more and more prominent Democrats are questioning whether the debt limit is even constitutional.

Let's have a look, shall we?

Article. I.  Section. 8.  The Congress shall have Power... To borrow Money on the credit of the United States;...

So, yes: if Congress has delegated that power to the executive, then the delegation is unconstitutional.  Only Congress has the authority to borrow money on the credit of the United States.

Likewise, I've held for many years that the War Powers Resolution is unconstitutional in that it delegates to the executive the power to start a war.  (Responding to a war started by someone else is another matter entirely, but deciding to start a war absent an attack or imminent threat thereof is clearly a power of Congress, and may not be delegated.)

 

Can't make it easy, can they?

Writing some firmware for an AVR-based thingie.

Unlike the AVR firmware I've written before, this includes some stringy stuff, like a little interactive monitor.

Makes sense to squirrel the constant strings away in program memory and leave them there, right?

Well, it's a little more complicated than that, on account of the Hahvahd architecture; program memory is actually a separate address space.  So, there are special access instructions and functions.

Now, this gets annoying: avr-gcc provides the whole PROGMEM thing... but it doesn't really work the way you'd expect.

You'd think that if the compiler had placed an array of structs in program space, it would know how to get at the structure elements, but no: it requires manual intervention.

So, not only do the individual strings need to be explicitly placed in program space, but the references to them need arcane dereferencing, thus:

struct monitor_cmd {
	prog_uchar	*cmd;			// Command name
	prog_uchar	*summary;		// Short explanation
	PROGMEM void	(*handler)(void); 	// Handler function
} monitor_commands[] PROGMEM = {
	{
		.cmd = s_report_cmd,
		.summary = s_report_sum,
		.handler = do_report,
	},
	{
		.cmd = s_hv_cmd,
		.summary = s_hv_sum,
		.handler = do_hv,
	},
	{
		.cmd = s_debug_cmd,
		.summary = s_debug_sum,
		.handler = do_debug,
	},
	{
		.cmd = NULL,
		.summary = NULL,
		.handler = NULL,
	}
};

...

	for (i=0; pgm_read_word(&monitor_commands[i].cmd) != NULL; i++) {
		strncpy_P(x, pgm_read_word(&monitor_commands[i].cmd), 16);
		printf("s: %04X => %s\n", pgm_read_word(&monitor_commands[i].cmd), x);
		
		if (!strcmp_P(cmd, pgm_read_word(&monitor_commands[i].cmd))) {

... and so on.

Man! Them revenooers is quick!

Just went to the bank to deposit a check.  My balance was lower than expected... by about the amount of two checks I'd mailed Wednesday afternoon, for estimated taxes.

Home again, check my account activity.  The state and federal estimated tax checks, mailed on the 15th, both cleared on the 16th.

(Now, if the account had been as low as it proved to be, and it hadn't been because those two checks had cleared already, there would have been a frantic flurry of what-happened-here, though no actual panic of how'm-I-gonna-pay-the-bills.  My accounting is sloppy, but I can get away with that 'cause I keep a buffer, which also keeps the bankers attentive.  In a good way.)

 

Friday the 13th come on a Monday this week

Gah.

All day in front of the computer.  Up crazy late.  All the time bashing my head against this FPGA design... and most of it on bits that are meant to be open-sourced eventually, thus are non-billable now.

Basically, I was tidying and repotting the synthesized-MCU code that I'd gotten working last week.

Just about the time I got all the memory to synthesize into block RAM instead of distributed RAM, things went all strange... and the memory evaporated, along with nearly all the logic.

Apparently fixing one interconnection bug unmasked another, and the unmasked one caused a cascading optimization of modules into oblivion.  ISE, naturally, was entirely unhelpful about the sequence of these optimizations, with "View RTL Schematic" giving the impression that a key input signal had been assumed to be a constant zero, when in fact the non-connection of a key internal signal had led to the destination logic for that input being optimized away, along with everything downstream of it.

And apparently enabling power reduction results in incomprehensible warning messages, such as Power:1531 and Power:1583, both of which are complaints that one or another I/O signal has invalid Bank assignment.  Eh?  Oh, well: looks like worst-case total power consumption, once I get the design finished, will be on the order of 125 mW, giving a die temperature a bit more than 5 C above ambient, so trimming milliWatts isn't all that urgent.

The real gotcha of the day, though, turned up in the static timing analysis.  The Spartan 6 PLLs can run anywhere from 400 MHz to about 1 Ghz.  The multiplier can be from 1 to 64.  So... it's reasonable to use a 10 MHz reference clock, a multiplier of 60, and a PLL frequency of 600 MHz, right?

Not so fast.  The fine print says the minimum clock input to the PLL is 19.001 MHz.  Er, Xilinx?  That says the multiplier can't really be 64, doesn't it?  (OK, so maybe that's for a hypothetical -8 speed grade.)

And here the first prototype hardware is supposed to turn up Any Day Now... and now I need to procure a suitable 20 MHz oscillator and do some rework.

Mnfxt.  Late Night.  Stress.  Didn't sleep well.  Up early because I was awake(-ish) anyway.  Got the sucker to synthesize properly this morning, I think - at least, it's using about the right quantity of resources.  Remains to be seen if it'll run.

 

99 bounces of spam on the wall, 99 bounces of spam...

Well, OK, so only about 90 of the 99 messages in my inbox this morning were spam bounces; apparently somebody used one of my addresses (specifically, the address of record for my domain names) as the return address for a bunch of spam sent to sundry Russians and Ukrainians by a botnet.

And so I had a bunch of bounce messages, mostly in Russian and Ukrainian.

Wait... bounce messages?  For no-such-recipient, rejected-as-spam, and mailbox-is-full?  Things that should be caught during the mail transfer?

My mail server is housebroken.  If it detects an error (including an excessive spam score) before the end of the DATA phase, it rejects the message with an error to the SMTP peer.  It doesn't accept the message for delivery, then discover the problem and send an error message to the (probably forged) sender!

The forged-sender problem has been around since forever, and nobody in his right mind would (since maybe 1995 or something) routinely believe that spam actually came from the address shown in the From: field.  (The last couple of months, I make an exception for compromised Yahoo accounts, but that situation manifests itself as spam from somebody I know, addressed to various people who might be in the apparent sender's address book.)

So how come there are still mail servers out there that send bounce messages to the sender, instead of returning a failure message to the actual sending host while the connection is there?

 

FPGA: the fun continues

Still having, um, fun, yeah, that's it, fun!!! with that AVR core.  Now I've got proper valid code for that model (I think), but the CALL instruction is... well....

It pushes 2 bytes on the stack, and jumps to the specified address.  So far so good.

Thing is... the first byte is supposed to be the low byte of the old PC, and the second byte, the high byte.  This what the VHDL looks like it ought to be doing.

Alas, looking at the bus cycles during which RAMWE is active, the first one has the high byte of the PC, which in this case is zero, and the second one has nothing, which presumably is always zero.

Since people are supposedly using this core in Spartan 3 land, and they've pretty much got to be returning from subroutines, either (a) something is synthesizing differently on this here Spartan 6, or (b), oho, mayhap the data leads the write enable by one bus cycle.  Another tweak to the ol' logic-analyzer connections should test that one.

A recompile later:  Aha!  Pipeline trouble!  </daffy>

Sure enough, the write data shows up on the bus one cycle ahead of the address and write enable.  For a single-byte write, this doesn't matter, because it's still valid on the write cycle.  For a multi-byte write, it causes problems.

Guess I need to insert a pipeline register in the data path.  Easily done.

A bit of fiddling later: YES!  </orson brain>

Adding a one-clock pipeline in the CPU-to-RAM path makes things line up right, and now my subroutines return, and I can call printf, and it prints and come back.

It's aliiiiive!

Development of the actual firmware can now proceed.  And the actual hardware it's meant to run on ought to be turning up some day soon....

 

I think this warning may be unnecessary...

...on multiple counts.

Recently got around to buying Theo Gray's Mad Science.  Just started reading it; lotsa fun stuff to ponder, though much is far outside the range of what I could reasonably do at home, for a variety of reasons, such as being unreasonably dangerous.

The werewolf-repellent project, though, comes with this warning:

Whatever you do, don't ever try firing silver bullets out of real guns, which are designed for lead ammunition.  While relatively soft compared to other metals, silver is still harder than lead and will act differently.  The likely outcome of such an attempt is death by explosive failure of the firearm.

OK, last things first.  I've seen several accounts (spread over many years) of catastrophic disassembly of smallarms, and most (amazingly enough) didn't involve serious injury to the shooter.  Death due to such an event is in fact quite an unlikely outcome.

(Actually, I've heard some totally insane stories of inappropriate projectiles... like the guy who had a 6.5mm Japanese rifle rechambered (not rebored) to .30-06, and fired several 7.62mm bullets down that 6.5mm barrel without obvious damage.)

Anyway: lead bullets, other than those for .22s and some antiques and replicas, are actually cast from alloys which are a good bit harder than pure lead.

And then there's this: most modern firearms are designed for jacketed bullets.  The (soft) lead core of the bullet is surrounded by a gilding-metal (copper alloy) jacket, which is what has to deform when it encounters the rifling.  There are also steel-core rifle bullets, which again have a layer of gilding metal to engage the rifling and provide a gas seal, without benefit of the soft core.

So the real question, if we're worried about hardness, is the relative hardness of silver and gilding metal... both of which appear to have a Vickers hardness of about 65.  (Based on two different sources, which may or may not be using the same Vickers units, so don't go betting your right hand on this.)

Ergo, a silver bullet should be no more problematic than one made of solid bullet-jacket metal, assuming the hardness numbers I scared up are actually using the same units (which I'd try a bit harder to verify, were I anticipating a werewolf apocalypse).

(Hm.  Wikipedia shows copper being a fair bit harder than silver, which would tend to confirm my notion that silver bullets are fine... except that I'm pretty sure Wiki's units for Brinell hardness are garbled.)

 

Breakthrough!

The past few days, I've spent much time bashing my head against the problem of building a microcontroller into an FPGA, using a synthesizable core.

I'm using The Wonderful AVR8 Core of Ruslan Lepetenok, as seen on OpenCores and used in Papilio.

Thing is, it's not real well documented... as in, there doesn't seem to be a handy document explaining the required timing relationships among the various signals.

Also, it's written in VHDL, and I'm speaking Verilog these days, so there's a certain difficulty trying to read somebody else's code that's written in a foreign programming language.

And I can't just embed the Papilio code as-is; for one thing, it'd need to be adapted somewhat for Spartan 6 use, and for another I need a wildly different set of peripherals... one of which is an SPI flash controller that uses DMA to do initial program load*, which implies rather nonstandard memory (and CPU reset) requirements.

Anyway, after a few days of head-bashing involving silly mistakes on my part, like not having the buses hooked up right, and after much fiddly soldering to connect a centigrid header to the Spartan 6 eval board so's I could hook up a logic analyzer to a decent number of FPGA pins... I saw the CPU come out of reset, load what looked like reasonable-ish numbers out of the first couple of words of program memory, and... take a flying leap into hyperspace.

A bit of further investigation revealed that the AVR core expects to be dealing with straight-up static memory, whereas Xilinx's memory core generator does only synchronous memory... so there's always one clock cycle involved in an access, no matter how slowly you're running.  So, the processor was getting its instruction word one clock late... ergo, seeing the word at address 0 twice... ergo, jumping to word 0x940C.

Hooking a 2X clock up to the memory cores had (at least, for a first approximation) the desired effect: according to the front-panel lights (or, rather, the antique logic analyzer standing in for even-more-antique front-panel lights), the processor is coming out of reset, jumping to word 0x0046, and then doing things that look more or less reasonable.

I'm thinking that an out-of-phase memory clock might be better than a 2X clock, but that can wait until tomorrow.

Anyway, tomorrow: first thing (after household chores) is to get this thing to send the letter 'Z' to a serial port.

Then to make it wait for characters, and echo them.

After that... well, the rest is easy.  Throw together some rinky-dink serial-port monitor with reasonable extensibility, and I'll be set for hardware bring-up when the real boards come in, probably early in the coming week.

 

* If the number 60133 sprang to mind, You Might Just Be A Data General Geek.  Yes, it's much like IPL on an old mini.  No, I didn't seriously consider using a NOVA core, mainly on account of not having a toolchain handy.

 

Update: Got the 'Z' sent just after breakfast.  Then off to chores; now (luchtime) back to work, and the echo progam is running (complete with mangling the character to prove it really went by way of the processor).

So: synthesized AVR core, program memory, and UART are working.  I think the UART wants a more suitable clock frequency; dividing 20 MHz down to a 16X clock for 115200 Baud gives a substantial error.  Since the TX/RX data registers are designed to cross clock domains, and the clock manager has plenty more tricks available, this should not be a problem.  (I do need to revisit the TX IDLE status logic; TX RDY is present after reset, but not TX IDLE.)

If the data memory also works, I'll be able to call printf, and if I can read from the UART and use printf, then it'll be all (well, mostly) downhill from there.

Oh, and a happy note: the Spartan 6 seems to be much less finicky about the SPI configuration signals than the Spartan 3E.  I can leave the Aardvark hooked up to the SPI header, and the FPGA still loads just fine, despite the long and untidy wires.

And maybe, IMCFT, I'll write up some helpful user documentation for that AVR core.

Update 2: For a while, it looked like RAM wasn't working.  Now it appears that RAM is working... but either avr-gcc is sometimes generating wonky code, or perfectly good code is sometimes not doing what it ought to.  The latest development: the LPM instruction doesn't appear to be working, and in fact seems to be returning the result of the last LD.  This is consistent across code tweaks and recompiles, so it's presumably not a timing issue.  Perhaps the core doesn't work properly on a Spartan 6 for some reason?  I suppose I could try adapting the Papilio project to work with a Spartan 3E board I have handy (would require re-doing the UCF, but maybe only a few lines of it, and the rest of the pin assignments could just be deleted and left up to the compiler's discretion).  If it works on the 3E but not the 6... oog.  I really don't want to dive into that forest of Somebody Else's VHDL without a map.

Or maybe it's an optimization thing, and I just need to find the right tweaks in the process settings.

Update 3: Oho!  The LPM instruction comes in three forms:

    LPM            # (r0 implied)
    LPM    rd,Z
    LPM    rd,Z+

It seems that this here core only decodes as LPM opcode 0x95C8, i.e., the first, ancestral form.  The avr-gcc output, meanwhile, is using the other two forms.

So maybe I need to tell the compiler not to use those... time to dig into the AVR-specific options to gcc (and worry about the presence of the third form in what appears to be startup code).  I compiled for ATmega64; perhaps this was the wrong choice.

...Ah.  Examining the datasheets, I find that the ATmega103 has only the first form of LPM, while the ATmega64 has all three.  So: try compiling for the 103.

/bin/go

Now my memory dump does... oh, foo.  The part that's reading from program memory is now returning correct data.  The part that's reading from the bottom of real RAM, starting from 0x100, is showing power-up default contents... because... the 103 memory map has RAM starting at 0x60.  Grrrr.

Anyway, it looks like the CPU core is indeed working, as long as I use the right instruction set.  Now I just need to figure out how to tell avr-gcc to use the m103 instruction set for compiling, the m103 startup code, and the m64 memory map... or, cram my peripherals into 64 bytes (0x20..0x5F, memory mapped), which shouldn't be too much of a problem, especially if I shrink the SPI command buffer from 32 bytes (enough to hold typical write data, too) to, say, 4 bytes.

Maybe tomorrow I'll get printf working (in among all the interruptions).

Update 4: To get a custom memory map, copy, e.g., /usr/lib/ldscripts/avr3.x to your source directory, renaming it, e.g., "ldscript.ld" and changing the memory definitions to suit your target, and update your Makefile thusly:

MCU_TARGET     = atmega103
MCU_DEVCODE    = m103

override CFLAGS        = -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) $(DEFS)
override LDFLAGS       = -Wl,-Map,$(PRG).map,-Tldscript.ld

Update 5: During RAM write operations, the data shows up on the bus one cycle ahead of the address and the write enable.  This is fine for single writes, as the data will still be there when the write happens.  For stack pushes, though, it causes trouble.  So: add a one-cycle delay to the write data (dbusout) path, and all's warm and snuggly.

Update 6: During I/O write operations (OUT, SBI, CBI), the data is placed on the same bus... but it's not a cycle early.  So the added pipeline register needs to be bypassed if it's an I/O write cycle.  Since the compiler will helpfully use these instructions for RAM addresses which are in range, it's important to have the I/O write operation work correctly.

 

Time for a Weinergate post

I've just come up with the perfect excuse!

The Wienerwurst dude was playing a variant of a variant of a smartphone version of "Where's Waldo."

In this version, Waldo is downgraded to Pantograph, and thence to Underpantograph.

The Underpantograph having been sent to an unknown destination, there follows a mad scramble to find it.

As we have seen, this can result in considerable collateral damage, especially if Underpantograph is in many places instead of just one.

 

Aieee!

As long as the camera was on the table, drying out from the rain that arrived (Unexpectedly^TM!) during morning walkies, I decided to grab the last 2 months of photos off the memory card.

Extract card from camera.  OK.  (Transcend 32 GB card, bought from Amazon a few months back, or maybe it was from one of those other businesses that sell through Amazon.)

Insert card into reader that I think handles SDHC.  OopsCRUNCH!  With just the usual gentle push, the card's plastic case bent.  Badly.

System log shows a 32 GB device connected: 63404032 512-byte logical blocks: (32.4 GB/30.2 GiB).  The file manager shows... gibberish.  The system log shows attempt to access beyond end of device and want=1073758048, limit=63395840.  Uh-oh.

Unmount.  Retry, using a reader that I know handled this card before.  Now the system log shows 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB) and unknown partition table.

Wunnerful.

Maybe some critical trace got broken somewhere in the process, causing the controller chip to decide the device capacity is 1 GB instead of 32.  And maybe the actual memory didn't get totally corrupted.  And maybe I can patch the broken trace and recover the filesystem enough to retrieve my photos.  And maybe we'll get a balanced Federal budget this year.

 

Download strangeness, once again

And so it came to pass that I found myself in need of the latestest Xilinx tools (ISE 13.1, where I've been using 12.4).

Point Firefox at Xilinx.  Click, click, username, password, next, Entitlenow Download Manager.  Which sits there at 0%.

Try again.  Same.

Oh, great.  Do I need to muck about with my firewall?  Is Download Manager trying to use some port that I've got blocked, or that doesn't get NATted properly?

Well, let's try it from the server.  Exit Firefox on the workstation, to avoid conflict.  Run Iceweasel on the server.  Xilinx.com, click, click, username, password, next, Save As...

Huh.  No Download Manager, and the download starts.  But is projected to take upwards of 4 hours, during which time I can't fire up my regular browser.

So: kill Iceweasel, and fire up Opera back on the workstation.  Xilinx.com, click, click, username, password, next, Save As...

Looks like it's working.  Apparently the Dreaded Download Manager is only invoked for supported browsers, whereof Firefox is one, so the secret is to use an unsupported browser to get a straight download.

And, while it's downloading, I guess I should be working on things that don't call for the latest version of ISE.  Documentation and such, maybe.

Oh, and when it's all done, I suppose I'll have to go through the peculiar rigamarole involved in making Webpack think it's properly licensed.  If memory serves, the last couple of ISE updates have required some jumping through free-license hoops, which were supposed to be automated, only the automation didn't work.  I think I ended up having to download the license thingy manually.

Update: Got 13.1 installed.  Tried to open somebody else's project that had been saved with something-beyond-12.4.  Discover that, while 13.1 will happily reopen any old project remembered from the 12.4 days, it refuses to open, from the Open Project... menu, a .xise file that has a hyphen in the name.  Or in the name of any of the directories leading to it.  Grumble!

Actually, I should probably kvetch to Xilinx about this, given that my real projects inhabit a directory called working-copies, with a hyphen.  I think this qualifies as an ISE bug.

Update 2: The hyphen thing is supposed to be fixed in 13.2, and there's a patch available (not tested here yet).

Really, though, Xilinx: you oughtn't be censoring path names!  Institutional standards may put all manner of characters in directory names.  Constraining the file names of HDL modules makes sense, but trying to force directory names into the mold?  And what's with Project directories must start with a letter (A-Z, a-z), and should contain only alphanumeric characters (A-Z, a-z, 0-9) and underscores (_).?  I can see wanting to keep an FPGA project under the model (or part) number for the firmware, and a lot of companies use straight-numeric, or numbers-and-hyphens, model/part numbers.

Update 3: The patch does in fact work (on 32-bit Linux, at least).

 

PWM spring

Today is a fine example: alternating bright sunshine and heavy rain.

In a more typical PWM spring around here, we have alternating days of summer and winter, with the duty cycle gradually shifting to favor summer.  Also, it tends to happen much earlier in the year.

This must be one of the new high-frequency PWM seasons, arriving late on account of new-product delivery issues.

Hm.  High frequency, with burst mode.  Looks like tomorrow might be vaguely summerish again, before the pulses of rain and hail return.

All just when I (a) need to be indoors getting work done, but also (b) need to be spending time outdoors burning off the winter coat and restoring my ability to spend the indoors time actually working instead of kvetching about the weather.