Re: board - T562.jpg

I think solderless breadboards are great when you aren't doing anything particularly fast or high-speed -- they really do improve productivity. There are many commercial microcontroller designs out there that you could still fully "design" on one. Obviously the kind of stuff you do wouldn't be applicable to solderless breadboard design...

Solderless breadboards are probably one of the mediums where it really is excess capacitance rather than inductance that keeps a design slow. :-)

When I was an undergraduate we already has labs where the professor was shown on a videotape at the beginning of the lab. A TA would then "help" with getting the labs working, although some of them were of course much more useful than others (the guys doing their theses on, e.g., optimizing compilers weren't much help getting photodiode amplifiers going... I wonder if Phil Hobbs was ever a TA? That would have been cool...)

I had some control systems lab where we designed temperature controlled ovens -- I left my soldered-together controller there for the TAs to use as the "golden model" since it didn't have the long-term reliability problems the prior solderless breadboards versions did!

---Joel

...and the computer-algebra system running on their calculators!

I hope that the "students are not to be trusted with untyped languages" idea is universal; I'd be shocked if there weren't universities where, e.g., Python isn't being used on a regular basis. (If John Larkin wasn't already quite so fond of PowerBasic I'd suggest he'd probably really like Python...)

That should be "ISN'T" universal.

I like the PB Dos version because it can directly access hardware. I can do INs and OUTs, and dimension an integer array *at* an address that just happens to be a VME crate or a PCI device. Under DOS or '98, of course. Or drop into assembly anywhere I feel like:

' \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ' \\\\\\\\\\\\\\\\\\\\ IN16 \\\\\\\\\\\\\\\\\\\\\ ' \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

SUB IN16(PORT, DTA)

' READ A 16-BIT PORT ' PORT IS PORT ADDRESS ' DTA IS RETURNED DATA

LOCAL P, D ' WE MAKE LOCAL COPIES OF PARAMETERS ' TO MAKE ASM LINKAGES EASY.

P = PORT ' RECOVER CALLER'S PORT ADDRESS

ASM MOV DX, P ; GET PORT ADDRESS IN DX ASM IN AX, DX ; READ PORT DATA INTO AX ASM MOV D, AX ; POKE DATA INTO BASIC VARIABLE

DTA = D ' AND RETURN HIS DATA

END SUB

' SEARCH THE PCI BUS FOR THE TUNDRA CHIP

ASM MOV AH, &HB1 ; THIS BLOCK OF ASM CODE LOCATES THE ASM MOV AL, &H02 ; TUNDRA UNIVERSE CHIP VIA THE VENDOR ASM MOV CX, &H00 ; AND DEVICE ID. THEN IT RETURNS THE ASM MOV DX, &H10E3 ; BUS NUMBER AND THE FUNCTION NUMBER ASM MOV SI, &H00 ; ASM INT &H1A ; ASM MOV RECODE?, AH ; RETURNED STS, 0 = SUCCESS ASM MOV BNUM?, BH ; PCI BUS NUMBER ASM MOV FUNN?, BL ; DEV/FUNCTION NUMBER

IF RECODE? THEN ' DO WE HAVE A CHIP? E$ = "TUNDRA CHIP NOT FOUND" GOTO FATAL END IF

' NOW USE A CONFIG SPACE WRITE TO RELOCATE THE TUNDRA

ASM MOV AH, &HB1 ; SUBFUN CODE = B102, WRITE CONFIG LW ASM MOV AL, &H0D ; ASM MOV BH, BNUM? ; BUS # FROM ABOVE ASM MOV BL, FUNN? ; AND DEV/FUN FOR TUNDRA ASM MOV DI, &H10 ; OFFSET TO PCI_BSO BASE ADD REG ASM DB &H66 ; USE 32-BIT OPCODE PREAMBLE ASM MOV CX, TUNLOC ; TO LOAD ECX WITH 32-BIT ADDRESS ASM INT &H1A ; THEN RELOCATE TUNDRA THERE!

John

Well, I have just done a SPI master/slave block *completely synchronously*. If you ever need one, email me (works up to a 4MHz at least, which is beyond the spec of the A-Ds I am controlling). Works like a charm (I implemented the Motorola style 4 wire interface).

I wasn't completely clear; I prefer synchronous design *where I can* There are times I can not. Then there are places it is obviously proper, but times it is not.

In an upgraded (being upgraded) design, I have removed a lot of parts in favour of an FPGA, and those parts must be duplicated from the perspective of the processor. As the interface was previously asynchronous, and changing interfaces is a royal pain, I have to implement an asynchronous bus. In such cases, I use delay tricks to make sure I get the timing I know will work with the measured (and documented) timings from the processor.

I could, of course, do synchronous design internally, *provided I run the clock fast enough*, but that uses precious power in a handheld unit and i can't live with it *simply for a bus interface clock* when it's perfectly possible to do it asynchronously. I handle the necessary synchronisation to the internal blocks with 2 FF resynchronisers. In this case, I would need to run the internal clocks at least at 50MHz which would blow my power budget.

That brings up a major advantage of asynchronous design; power consumption.

When my device sleeps, I *stop the clocks completely* except for the processor (which stops it's own clocks) and then restart things properly later; but the wakeup sequencers must be completely asynchronous.

So is synchronous design better? Depends on the question being asked.

Cheers

PeteS

That's great, but for those of us using lower power [and on a lower budget ;) ] devices, I could wish for the tools to obey my requirements, but that would be a 'vendor specific solution' unless I could get Verilog / VHDL changed to have a keyword where the synthesis / PAR tools would understand that 'this is not to be optimised in any way' on a perhaps module basis, rather than on a global basis (WYSIWYG comes to mind).

I've even gone to the extent of specifically instantiating primitives, and PAR *still* optimises them out, even though there's plenty of room for the logic, and I really wanted to do it that way for various reasons. I do not want the tools to try and think for me; software that tries to be that smart only succeeds in being dumb. I have written a

As John already noted, the fervency around synchronous design is almost religious. As I note in another post, it's preferable *most of the time*, but there are times it actually prevents me from doing things properly. One could hope the FPGA vendors and tool vendors might listen to experienced pure hardware designers on this.

Cheers

PeteS

_Me_ going back to software!

Muahahaha

Cheers

PeteS

One step closer to a synthesizeable VHDL "wait for 2 ns" statement! Not that I think it's a good idea, but newbies are always asking for it. :-)

If you really feel the need for async design, it can be done with utmost care on an FPGA, but such a design has to take into account the routing delays. The tools do not support specifying the routing delays beyond that needed to satisy synchronous operation, and for a very good reason (I'll address that in a moment). You can keep the tools from optimizing out pieces you need through addition of keep attributes. You can also instantiate primitives, which the tools generally do not remove (but you need to be careful with simple inversions or buffers), or you can create routed macros with FPGA editor. The hooks are there for manually doing your async design, and I have used them on the rare occasion. It is tedious and error prone, but everything you need to do it is there.

That said, the FPGAs and tools are targeted to the sync design audience, as that is the bread and butter of the industry. The analysis and design is far easier to get correct with synchronous design rules, and as a result the tools are far easier to design and use for those cases. Since the synchronous design domain represents the large majority of all digital design, and the tools for doing it are lower hanging fruit than what is required for async design, it is natural the FPGA vendors only target that market, and to not have any interest in the async market. The cost to entry is too high: tools are much harder to design and verify, there are many more gotchas that need to be covered and tested for, there is a potential for far more technical support needs, and on top of all that a market that is less than a percent of the total market. Why would any sane vendor even pursue that when there are so many other easier to obtain ways to make money?

Come to the open source side John.

Do you not have a disciplined backup approach? You can always get a 2005 or

Thanks for answering, Ray :)

I understand why the vendors don't specifically target the async market, although I will say that the software developers who do the tools don't always appear to truly understand hardware (it covers so many sins, I am not surprised, nor is it a complaint, more an acknowledgment).

As to making money, that is, to a great extent in any market, dependent on customer goodwill. Making primitives that won't be optimised away and not protecting me from myself when I so ask will make me far more likely to use such a vendor again, because they have listened to my requirements, and responded that such things are avialble. I take the responsibility if it goes wrong, *provided* I get proper timing output data from the tools. I'm not asking for autoplacement and guaranteed constraint mapping, just a report that tells me the various timing elements - then it's up to me.

I once implemented a binary search on file data (before the days of huge virtual memory and large memory in general) where I wrote the function and manipulated the file pointer directly (those fun functions that use SEEK_SET, SEEK_END, SEEK_CURRENT etc). During development I trashed a lot of file data (that's why we always use a test file, not the live ones ;) but the point is I am willing to do the work to make things work the way I need them to work.

Cheers

PeteS

Yup, I agree here. I really think the developers should be required to sit and use their tools on a design, but then they'd have to get up to speed on digital design first.

I'm not sure what you are looking for. You can dump speedprint if you really want to know the timing of elements (can you still do this, I haven't in several years). The timing of the logic is very well defined, but you'll also see that it varies depending on which pin is used. The timing of the routing is the fly in the ointment, because it typically represents 50% or more of the total timing between flip-flops in a synchronous design, and that route timing is of course quite sensitive to the exact route taken as well as to placement of the logic. Are you looking for a report of every route segment in the device? That is a huge report, not likely to be of much use. The static timing analyzer will report the timing of each element in a path, but the problem is combinatorial loops break it.

I want to know the static timing, no more, and I am aware it varies from pin to pin (well, duh). I am not asking for all possible routes.

Here's something I would like; in the floorplanner - an identification of timing by route (single route only) so I could actually choose a specific signal route.

;and then lock it.

Do-able?

Cheers

PeteS

Not in floorplanner, as floorplanner is a placement tool and is totally unaware of routing. You can do that in FPGA editor if you manually route rather than using autoroute. You can also create pre-routed macros this way.

Hmmm.... that opens up all sorts of new avenues (not to be told to the unwashed masses of course). Do those pre-routed macros get effectively locked? One would assume so, but I'll ask anyway.

Thanks!

PeteS

Attack my ass

If I can't gain complete access to the machine with a language, *I won't use it*. The fact that there are many who have no clue of what to do with it should not be an impediment to *my ability to develop solutions*.

Sounds like an ID Ten T error to me

Cheers

PeteS

Yes. You can also generate routing directives that can go back into the ucf to direct routing, although those are specific to the location (ie, not hierarchical).

We just solved a nasty problem with this:

A d-flop: D tied high; clocked from a pin, CE from internal gating logic. Its Q output drives a BUFG clock net buffer, and Q also feeds a delay line back into its own async clear. When the input pin rises, if CE permits, it makes a single clock pulse. Everything downstream is "synchronous" in that it's clocked from this gadget.

The delay line is a chain of AND gates (with transparent latches enabled in the logic cells, just to add a little more delay), with each fed from the ff Q and also from the previous gate. This is a delay line with a fast discharge mechanism when its input goes low, so we don't have to wait for the 0 to propagate through, chasing the 1.

John