fooling the compiler

We have a Spartan6/45 that's talking to 16 separate SPI A/D converters. The data we get back is different, but the clock and chip select timings are the same. To get the timing right, avoiding routing delays, we need our outgoing stuff to be reclocked by i/o cell flipflops.

So what happens is that we have one state machine running all 16 SPI interfaces. We tell the software that we want the adc chip select flops in i/o cells. The compiler decides that all are seeing the same input signal, so reduces them to one flipflop. Then it concludes that that flipflop can't be in an i/o block, and builds it that way. The resulting routing delays are deadly.

We couldn't find a way to force these 16 flops into IOBs. Really.

The fix is to fool the compiler into thinking the flipflop states are not the same. Turns out the the synchronous clear inputs to the flops are unused in our design. My suggestion was to ground an input pin, run that into the serial input of a 16-bit shift register, and route the sr taps to the clears of the 16 output flops. The compiler can't know that these levels are in fact always low, so has to gen 16 different flops. *Then* it allows the flops to be forced into IOBs.

Rob has a better idea, just make a 16-bit SR that generates a thermometer code on powerup, namely walk a 1 into it, and have the sr output bits un-clear the i/o flops sequentially. The compiler isn't smart enough catch onto that, and we don't need to ground a pin.

It works.

Isn't that all perfectly stupid?

The Altera folks are coming to make their pitch tomorrow. This story may amuse them.

John

Reply to
John Larkin
Loading thread data ...

The compiler isn't smart enough in its current version. You may be laying a trap for the future if you use a technique that relies on the compiler not performing an analysis that it could perform in principle, but just doesn't at the moment.

I suppose it doesn't matter if you sure that neither this circuit, nor any variant of it, will ever be processed by a newer version of the compiler.

Sylvia.

Reply to
Sylvia Else

That could only happen if the compiler figured out that you weren't looking at the output for the first 16 cycles. You can know that, but normally the compiler can't assume that.

That is, with the assumption that the SR initializes to zero and clocks a 1 in.

-- glen

Reply to
glen herrmannsfeldt

Did you try to attach a (* KEEP = "TRUE" *) attribute to the registers in question?

I had a similar problem with registers meant to get places in an IOB absorbed by the feeding BRAM

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

In Synplify, this common type of situation is easily handled with the "syn_preserve" directive which is different than Synplify's "keep" used for wires in my Verilog code.

It's good to get intimate with your compiler's list of attributes and directives. While it's often "pushing the rope" to get the results you expect, it's good to become more expert at pushing.

- John_H

Reply to
John_H

Am 25.06.2010 12:31, schrieb John_H:

Hmm, but is there a portable way to do these things? Something like C's "volatile"?

Philipp

Reply to
Philipp Klaus Krause

This design builds under v11 of the Xilinx software, but won't build under v12, the "Spartan 6 optimized" version. So there's apparently no worry that we'll ever compile it under more advanced compilers; they seem to be getting worse, not better.

John

Reply to
John Larkin

My Xilinx guy, a real pro at this sort of thing, tried everything, "keeps" and "forces" and such. He thought my suggestion was disgusting, which it certainly is, but it broke the logjam and let us get on with our lives.

The real figure of merit of any fpga is a mimimal value of

K = A/R

where A is the actual time you spend downloading, installing, patching, and fighting with the tools, and R is a reasonable design/sim/test time for the project. Xilinx's K value increases steadily over time, and is now roughly 4.

John

Reply to
John Larkin

I haven't done this recently, but in the previous versions of XST I found you had to shut off "equivalent register removal" AND "resource sharing" in the Synthesis properties, and also "equivalent register removal" in the Map properties to fix the issue. I have also used the shift register start-up approach to make the registers non- equivalent, but I didn't need to do that with all the switches set properly.

HTH, Gabor

Reply to
Gabor

Those setting become global to the design. If you use sensible HDL structures, that explodes the number of CLBs, so the cure is worse than the disease.

John

Reply to
John Larkin

Funny, that's my figure of merit for an embedded processor, too!

It's much better these days than it was 20 years ago, although I admit that I've managed to shove it way up recently by deciding to build my own open-source tools. But that's for play, not for money, so it's different.

--
Tim Wescott
Control system and signal processing consulting
 Click to see the full signature
Reply to
Tim Wescott

I'm still programming embedded stuff in 68K assembly. Dyno mode. The thing is, I finish a typical instrument's firmware in a week or two and have zero problems with the assembly and debug tools. And rarely find a bug in shipped products. I can archive the source *and all the tools* on one floppy. A lot of people nowadays can't even install and run tool chains that they used a few years ago.

Sometimes just grunting it out with simple tools is the best way to get something done. A lot of fancy labor-saving, abstraction-for-reuse stuff is actually game-playing and counter-productive.

John

Reply to
John Larkin

Good for you.

It can be. It works well when you have a large group and a product line with lots of components that have both similarities and differences.

I worked on a product that had over a dozen CAN-enabled processors roped together on a CAN bus. We had a _lot_ of common code that was reused among all the processors. We also had a lot of code that was individual to each processor.

Just handing out specifications for the CAN protocol to a dozen developers and telling them "go" would have been a nightmare. Instead we got the CAN stuff going with just two guys, and used it everywhere. Ditto for a bunch of motor control stuff that was used everywhere, as well as some generic ADC-reading infrastructure and other bits and pieces.

But I've seen code reuse turn into a disaster in the hands of someone who's not as smart as they think they are.

--
Tim Wescott
Control system and signal processing consulting
 Click to see the full signature
Reply to
Tim Wescott

Constraints usually help. In that case it should duplicate logic (if this option is on) to meet timing specifications.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

you don't happen to use the output of that flop somewhere in the design?

you can't directly instantiate an output FF, but you can instantiate a DDR output FF, OFDDRCPE, with C1 tied low it might work.

-Lasse

Reply to
langwadt

I understand your pain.

My gripe is that the tool views constraints as "suggestions". I place a CLB, I see the message "resolved that xxx is at yyy", it doesn't meet timing, and viewing the routed chip in PlanAhead reveals that 'xxx' is NOT at 'yyy'.

Hello? I wouldn't have created the constraint if it wasn't important! Getting documentation on what the tool actually does with constraints is like pulling teeth from a chicken!

I recently worked on a project where the design "just doesn't work" with ISE-11 and ISE-12. Works "just fine" with ISE-10, provided the "luck of the Irish" has the CLBs falling where I constrained them to be placed.

Xilinx: I know you keep asking me to open a web case, but I've never gotten anything resolved that way. This is a link to the design that does not work with versions 11 and 12: I've narrowed the failure to the synthesis of the exception module. Build, map, and par all seem OK (you're welcome).

How did the meeting with Altera go?

Gary

Reply to
ghelbig

That just confirms what I always say: A software tool is never so reliable as after it has gone obsolete.

Jeroen Belleman

Reply to
Jeroen Belleman

That's a simple consequence of software tools getting less reliable every generation.

John

Reply to
John Larkin

Turns out, according to Xilinx, that IOB=TRUE (which is a suggestion to the compiler) works, but IOB=FORCE (which is supposed to be mandatory) doesn't. We just left the shift register in there.

John

Reply to
John Larkin

I'm surprised that works. It didn't a couple of years ago, when I last used Xilinx stuff. The other thing to watch is tristate forcing. I found they had to be in the top level of the hierarchy to work right. Maybe that was just a problem with Virtex4 and the PPC stuff, though.

Reply to
krw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.