Re: board - T562.jpg

Well, this could fill a book.

One of my real pet peeves is I don't have control over the synthesis and PAR process such as have with C (for example - I've written many hundreds of KLines of C).

As an example, there are times I _deliberately_ want to delay a dignal by a prop delay or two, but the damn tools optimise it out. If I had a 'volatile' keyword, or perhaps 'pragma' to tell the tool to *leave this damn code alone and don't think of optimising*, it might be better.

This snippet for example;

wire sigA; // input sig wire sigB; // intermediate signal wire SigC; // output signal

BUF (a.sigA, b.SigB); BUF (a.SigB, SigC);

..

the tools will optimise them out when I _specifically_ want them there to add a delay. Of course, you can always say

SigC = #10 SigA;

but I prefer to use buffers because the timings are specified far better than the tools will do what I want.

Windows based scopes - I have always said that a smart power switch on a windows machine is the dumbest thing I ever heard of.

No - I agree with you. Real hardware is properly parameterisable and not subject to the latest 'thoughts' of a software engineer who doesn't have a F***ing clue about hardware.

Cheers

PeteS

and further (yeah, I know I had typos in the previous rant)

When I do pure hardware I do not have to try and figure out what the hell was done to implement my statements.

This was a major issue on a design I did about 4 years ago where I interfaced an upstream bus to the busses on 6 devices (with a lot of other stuff) and the synthesis / PAR etc kept optimising away certain things that were there to maintain the timing. The response I got was 'well, use pure synchronous design' but in this case it was simply not possible (am issue I am sure you'll understand).

I once deliberately did a DeMorgan transform by hand because I did nto trust the tool to do it right. (Code available on request ;) )

Cheers

PeteS

Yup, this *is* the real world. We recently had to do a clock-edge deglitcher, using delay elements. It couldn't be synchronous, because we were, well, deglitching the clock! Ditto stuff like charge-pump phase detectors, where you really need exactly what you need, delays and all.

One thing you can do is add a pulldown to a pin (or ground it) and call that signal ZERO or something. Then just OR it with things to create new, buffered, delayed things. If you need more, run it through a shift register and create ZERO1, ZERO2, etc. The compiler can't optimize them out!

So the FPGA software people ought to provide us an irreducible ZERO without wasting a pin, or a buffer that stays a buffer always.

So, is there a block of logic so complex that the compiler can't figure out that it indeed will always output a zero? Maybe the MSB of a thousand-year counter, but that wastes flops. Maybe some small but clever state machine that always makes zero but is too tricky to be optimized?

John

As noted, I once did a DeMorgan transform by hand (simple one too) and it materially changed the compiled output. (For those who understand the transform, don't get upset at the comments; they were there for people who _didn't_).

Here it is:

else begin cs0

They should back off this religious devotion to fully synchronous logic and give us a couple of dozen programmable true delay elements, scattered about the chip. But they won't because it's not politically correct, and because they figure that we're so dumb that we'd get into trouble using them.

John

What exactly did the tool do with this design? I don't see anything that will tell the tool not to optimize the logic and eliminate your gates entirely. Logically your equation is equivalent to the original input signal. There are attributes you can give a signal to prevent the tool from optimizing it away, did you use one on cs0?

I also don't see what advantage your DeMorgan transform has. If you lock the cs0 signal so that it is not optmized away, the tool will use a LUT to produce cs0 from cs_I. It will also use a LUT to do the OR.

There are delay elements built into the IOBs of Xilinx parts. I don't recall just what you can and can't do with them, but if you run a signal through the delay and also run it without the delay, you can then OR the two in just the way you intended above. This may require two input pins however and it may not be usable unless you are running the signal into the input FF, I'm not sure.

"John Larkin" schreef in bericht news: snipped-for-privacy@4ax.com...

Well, synchronous design is easier and more understandable then asynchronous. So the "specialists" tell the world synchronous design is the only way rather then confess they are unable to make reliable asynchronous ones. And let's be honest. A lot of old asynchronous designs are real nightmares of critical race conditions, ad hoc inserted RC delays, glitches and tricks. Good asynchronous engineering is rare and was rare even in the days synchronous design was not yet invented. (Practised may be the better word.) I ever was asked to "debug" a time critical circuit. Looking at the asynchronous circuit which failed only once a week or so and reading the full page of explanations about the inner workings I discarded the whole design, doubled the clock frequency and made a rock solid synchronous circuit. They were almost disappointed it was that "easÿ". I could have made disciples for "synchronous only" but I'm not a true believer myself. Times they are a changing. I heard rumours asynchronous design has a revival as it can be used to build faster circuits. There should be special software for it, meant to design processors and the like. It's those software that makes me shiver. When the first micros hit the market, an engineer complained that those programmers used lots of extra space. He would have been fired by using only one percent of that number in extra gates. (Nothing to do with old uncle Billy :) Things did not grow better ever since but the real bad development is the habit of those programmers to think and make decisions for me. I really hate that. Almost all of these programmers have a theoretical background in "software engineering". Ever visited such a college with lots of computers, tens of masters and hundreds of students and no one could handle a soldering iron. There was none in the whole place. An assistant brought his own one from home when he needs to repair a cable. None of those "engineers" ever wrote bugfree software, but expect hardware designs to be it. Nevertheless, if something goes wrong, it's inevitable a hardware failure. I ever had technicians to exchange hardware seven times before they stopped to deny it to be a bug in the software. Another time one of my collegues disassembled a floppy driver to prove it did not met the drive specifications. (It could not format a floppy and they insisted we used the wrong brand of floppy although we tried every brand we could lay our hands on.) They complained about the disassembly rather then admit their own failure.

Well, maybe we're doomed. Maybe I'm going to write software. What's worse? :)

petrus bitbyter

I'm thinking about it... can't you do all analog functions with a uP now anyway ?:-)

...Jim Thompson

"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...

You're some sort of smug bastard on the quiet. Obviously they can, it's just that your crappy analog electronics isn't fast enough to make it viable. Instead of sitting on the sidelines and sniping you should get your finger out.

DNA

There are some people doing serious (cpu-scale) async logic, but that's pretty thin-air stuff. What I meant was that, even in a properly synchronous design, there are times where a real, analog delay is a useful design element, and it sometimes can save a full clock worth of time... not all data paths need a full clock to settle. Plus, it would be nice to be able to dynamically tune data:clock relationships and such. I have one architecture that we use a lot that simply must have a real, unclocked one-shot (among other things, it stops and resets the clock oscillator!) so we have to go off-chip to a discrete r-c.

I toured the Cornell EE department recently. 95% of the screens are on PC's, maybe 5% are oscilloscopes. No soldering irons in sight, just those drecky white plastic breadboards. Tulane, my alma mater, used Katrina as an excuse for eliminating the EE department entirely. I guess those labs are too expensive, compared to one TA teaching 400 kids art history in a lecture hall, all at once.

Yeah, there is a lot of ad-hoc async stuff around, full of 555's and one-shots and race conditions and such. Disciplined sync design should be the starting point from which to cheat.

I'm stuck, all this month at least, rewriting a diastrous, 14,000 line mess (68K assembly) that took over a man-year of work to make this bad. Programming is OK, but after a couple of weeks of it I get depressed... too much like bookkeeping. I can design hardware forever.

Gotta do the ghastly serial DAC driver next. The Xilinx bit-bang serial config thing worked like a charm, even blinking an LED during the loop.

John

There's rarely "the only" way. However alternatives may be hard ;)

If you have access to the source those issues are easier to workaround..

In many places students get by through pure theory, and occasional lab. Access to labs are scarce outside the formalised sphere. Which will deter many persons from trying on their own. Theoretical tests are premiated substantially, and that is what you get..

I heard an interesting comment once, students are not to be trusted with untyped languages because they can't handle it. STILL same persons are expected to handle advanced math with pen & paper.. Maybe they expect correct math and spaghetti implementation? :-)

Maybe because failure to pay attention in hardware have such dire consequences directly? :), you can't undo/recompile the magic smoke..

Can't rewrite it in C or so .. ?

How about programs such as Solidworks that are only one-way upward compatible. I.e. you can open a part or assembly file created in SW

Best regards, Spehro Pefhany

I'm c-phobic. It looks like monkeys pounding on typewriters to me. The

John

Virtex4 has them. They are the idelay elements, which give you 64 steps of delay with 75ps granularity.

Almost 5 ns! Most cool.

John

John,

I think the real problems are that:

2) You're correct, they do figure that "you" [as a whole] will get into trouble using them. You -- personally -- clearly won't, but if you're running a business it's clearly useful (to your bottom line!) to set up the system so that you try to protect people who don't know what they're doing from blowing their feet off. That being said, this approach is often taken too far to not only keep a couple of the more advanced "doors" closed, but to put locks on them altogether. I've seen software development tools go this route as well -- they're perhaps improved and easier to use for novices, but actually harder and less functional for experts. These days I have to hold my tongue rather than go around claiming things aren't "expert friendly," because it is seen as an attack somehow on the less-than-expert users. That's where the political correctness BS comes into play!

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...)