Xilinx Schematic Entry

There is no translation to an HDL assuming you mean RTL format. The schematic needs to be converted to textual format (most often EDIF) but it is just a structural netlist very much like the output of the synthesis ie LUTs, INIT statements, DFFs, etc only what ever directly can be mapped to the FPGA. So you get quite a bit more control over what actually goes into the design than an RTL which needs to be synthesized.

Maybe I'm misinterpreting what you wrote here, but I don't think this is true. I have done both schematic and VHDL designs in Xilinx. My current favorite scheme for schematics is to enter the schematics in Protel, generate EDIF files for each sheet, tweak them to be compatible with Xilinx, and add them to the design. (I'm still stuck at ise 5.2, as I need 5 V compatible software.) I found the Xilinx scematic editor to be a HUGE pain.

But, either the EDIF way or the Xilinx schematic entry way, the result is NOT LUTs and such, directly. It gets turned into an HDL description of the logic funtionality, for the most part. If you include macros with pre-compiled slices, such as the carry chain or other architecture-specific structures, then those do pass through pretty much directly. But all the other logic is reduced to the boolean equations, and these are then synthesized using the exact same tools as if you had entered the HDL equations in your favorite HDL.

As for the original posters comment "My contention is that the

schematic you draw isn't always how the design is implemented in the

chip." He is exactly right. You can arrange all sorts of trees of gates, but the tools will turn it all into equations, minimize the HELL out of them, and render that logic. Just try throwing in a string of inverters to delay an external signal, for instance, and see what happens!

So, I don't think the schematic entry provides any greater control, assuming the FPGA-specific macros like carry chain, DFF, GBUF, are available in your HDL.

Jon

Eli-

I'm not sure what synthesizers do with schematic translation -- minimized and optimized, or rendered faithfully with precise control -- but I can tell you a few other reasons why schematic entry other than top level with modules (good documentation practice) is not a good idea. The main one is there is just no support. Try asking Xilinx to help with issues regarding schematic entry and see what happens. Another one is the thing quickly becomes huge and out of control. Page after page and easy to overlook a misconnected line on one of those 32-bit busses or muxes. The third one -- my favorite -- is the

20-something engineers you work with will call you Gramps and ask you where's your DOS editor and Tektronix analog scope for that beast :-)

-Jeff

To do a delay with a string of buffers, you can either persuade the compiler to not strip the intermediate nets, or, more fun, use gates for the string and connect the other inputs to something that really doesn't matter, but is too complex for the optimizer to understand! Like a string of ANDS, with all the side inputs connected to an i/o pin that has a pullup, so that the optimizer doesn't know you never pull it down.

There could be a whole family of "fool the compiler" techniques.

John

Except that I can flip through a 20-page schematic and not only understand what it does, I can usually spot hazards and bugs quickly, sometimes in seconds. Nobody can do that with a few thousand lines of uncommented HDL.

Parallel beats sequential, which is what FPGAs are all about.

And if they call you Gramps, it's easy enough to fire them and hire a fresh batch.

John

John-

Sure if it's OrCAD, which we use it for complex board designs. Yes you can spot errors fast and things jump out that can save your board desgin.

But ISE? A 20 page schematic in ISE is like trying to cut concrete with knife. You can do it, but only if you have a LOT of time on your hands, maybe for example a need to escape from prison :-)

-Jeff

Eli Hughes schrieb:

Hi Eli, The schematics from the XILINX ECS Tool are converted by the sch2hdl tool to structural hdl. Either verilog or VHDL. The resulting Files are named *.vhf for VHDL flows (not sure about the verilog file naming rule). From the schematic libraries within ECS you can use gates, FFS and complex functions like counters muxes etc. These become optimized by e.g. XST into LUTS and FFs etc.

Just for fun: Load a *.sch file and it's resulting *.vhf file into an editor and see what's really happening.

The question about how much control over the synthesis results you have from your input file depends on a lot of things.

What style of hdl code are you writing (structural, RTL, behavioral ?) Do you use attributes in your HDL?

What elements does the schematic guy use? Slice elements (LUTS FFs etc), simple gates and FFs or complex function blocks? Does the schematic guy use attributes in his schematic?

Compare your styles and then you can argue about control over synthesis by the input files.

have a nice synthesis Eilert

PADS has a beautiful schematic editor.

Well, the library symbols sure are hideous. What *were* they thinking?

Too bad there's no universal schematic file format. Schematics would be more pleasant if, for example, old Foundation schematics could be imported into ISE; it's criminal that they can't.

LT Spice seems to have a nice external ASCII file format for expressing schematics.

John

Now if you use the Altera Quartus schematic capture I personally believe you get a superb set of tools and symbols.

Here is an example I dropped together inside 3 mins, ready to synthesise. Only needs the pins and device defining before I can drop it straight into a part.

I bet not many engineers cannot see what the intent is in this extreme trivial example....

..... as opposed to shedloads of VHDL which would take a week and numerous sketches to work out what is going on, looking for typos and missed declarations etc.

But then I am just an old Gramp and prefer a cushy life.

Slurp

Very nice.

Or you can buy an expensive software thingie that turns your VHDL into a (very, very ugly) schematic to help you understand what it does.

John

Here is my verilog take on it:

module block1_bdf(sysck, a, b, c, d, e, result); input sysck; input [17:0] a, b, c, d, e; output [37:0] result;

reg [17:0] dataa, datab, datac, datad, datae;

always @(posedge sysck) begin dataa

OK, so say I wanted a low pass, and wrote:

/* 12.5 MHz clock chroma lowpass */ `define F0 0 `define F1 -2 `define F2 2 `define F3 8 `define F4 -3 `define F5 -21 `define F6 5 `define F7 80 `define F8 127 `define F9 80 `define F10 5 `define F11 -21 `define F12 -3 `define F13 8 `define F14 2 `define F15 -2 `define F16 0

module fir( clock, fir_in, fir_out); wire clock; input fir_in; output fir_out;

wire [7:0] fir_in; reg [7:0] fir_out; reg [31:0] temp;

reg [7:0] sm0; reg [7:0] sm1; reg [7:0] sm2; reg [7:0] sm3; reg [7:0] sm4; reg [7:0] sm5; reg [7:0] sm6; reg [7:0] sm7; reg [7:0] sm8; reg [7:0] sm9; reg [7:0] sm10; reg [7:0] sm11; reg [7:0] sm12; reg [7:0] sm13; reg [7:0] sm14; reg [7:0] sm15; reg [7:0] sm16;

always @(posedge clock) begin sm16 = sm15; sm15 = sm14; sm14 = sm13; sm13 = sm12; sm12 = sm11; sm11 = sm10; sm10 = sm9; sm9 = sm8; sm8 = sm7; sm7 = sm6; sm6 = sm5; sm5 = sm4; sm4 = sm3; sm3 = sm2; sm2 = sm1; sm1 = sm0; sm0 = fir_in;

temp = (`F0 * sm0) + (`F1 * sm1) + (`F2 * sm2) + (`F3 * sm3) + (`F4 * sm4) + (`F5 * sm5) + (`F6 * sm6) + (`F7 * sm7) + (`F8 * sm8) + (`F9 * sm9) + (`F10 * sm10) + (`F11 * sm11) + (`F12 * sm12) + (`F13 * sm13) + (`F14 * sm14) + (`F15 * sm15) + (`F16

• sm16);

fir_out = temp / 512; end

---------- How would you draw that?

It is interesting to note that xst will synthesize this, and it works, and does not even take that much space...... But I am sure somebody will scream....

hehe

My problem with block diagrams is that I can never simplify an algebraic expression when all '+'s and '*'s are shown as blocks. I recently did a simplification on some complex arithmetic data-path which reduced the number of 32x32 multiplications from 33 to 26 which enabled me to use one less multiplier (over 16 cycles). I don't think it could've done it without first converting the schematic to text and then work out the algebra (if the design were in schematics to start with that is ;-)

MK-

On the other hand, Slurp's great-looking example was mostly data flow

-- block diagrams are extremely good for depicting signal processing and other data-driven algorithms. You could take your optimized Verilog and go back to schematic form again and still be able to see what's going on.

But not so for protocols, state machines, bus switching, and other "control flow". All control flow paths must be shown in a schematic, making it difficult to clearly recognize one path or another and either focus on it or ignore it -- something easy to do with an "if else" in code or a "decision block" in a flow diagram.

-Jeff

The same way people drew FIR filters before HDLs were invented. It's very simple and very intuitive... looks just like an analog transversal filter.

John

On a sunny day (Wed, 05 Apr 2006 17:47:09 -0700) it happened John Larkin wrote in :

Sure, possible. But this IS a lot faster, and more readable in my view. Actually I tried it that way (you describe), and even to get a 64 order you will need a BIG piece of paper..... make it 32 wide... But nobody is stopping you.

Actually, some things, like FIRs, may as well be in a box on the schematic, and be HDL or whatever inside, as long as the function is routine, as an FIR is. Some stuff, like big address decoders for example, really work better as text. But the big picture, and even much of the control logic, make more sense to me as schematics... I can *see* what's happening in a flash, as opposed to reading and decoding 6000 lines of uncommented HDL. The schematics themselves should be heavily commented, of course.

I do like the idea of designing as close as possible to the chip's actual cell architecture, which I find easier to do visually.

Again, it depends on how your brain works. Schematics and HDLs are just interfaces.

John

For what it is worth, back when I was doing schematics I was using wrappers around flip-flops and gates that looked like state diagram elements. The state bubble contained a flip-flop , a decision block was contained pair of And gates and had one extra "pin" for the decision, and T junctions on the diagram had OR gates under them. It made for a very quick (in terms of schematic entry time) entry and easy to understand schematics.

the point is there are ways to make schematics much more usable in design entry, and they are more or less self documenting as long as they are done hierarchically, using sensible symbols and sensible partitioning. By the same token, HDL can be made to be horrendous as well. The biggest drawback to schematic entry in my mind is that the file format is proprietary, which makes it basically non-portable between tools (or in some cases between versions of the same tool), and you need a viewer to look at the files, where HDL entered design only needs a text editor to view the design.