Mike I use similar methods, just I'm not brave enough to let synthesis instantiate fpga drivers. Less work for me in a manual top wrapper than in keeping the ucf file in sync. IO drivers and clock stuff lives there.
With that extra layer I suspect the 'do twice' disappears. And its worth it for RTL simulation. john
John Sheahan wrote:
In the designs I have seen where I/O pads are instantiated in the RTL there is a top level wrapper. The wrapper instantiates the `core' of the chip, and also contains instantiations for the pad primitives. The I/O pads nets for the chip are coded with names that don't contain brackets or other characters that would indicate a grouping of signals. That is, if the core has an address bus 'A[31:0]' there would be 32 input buffers connected to discrete signals like `A31', `A30', `A29',...,'A1','A0', and the outputs connected to `A[31]', `A[30]', `A[29]',...,`A[1]', `A[0]'. This can be accomplished without any trouble with the current netlister.Its pretty common to burst busses for both asic and fpga pinouts. Tools I have used for that dislike busses.
If your very top level has to use a burst bus, where is the best place in the design representation to do it?
With a wrapper like this, you can instantiate the `core' separately from the I/O ring and get better performance in your RTL test benches. At least before the optimizing simulators take a shot at it, the test bench probably uses a bus to connect to the individual pins then they expand into single signals, then they collapse back into a bus again once inside the chip. All this scatter-gather tended to waste simulation cycles. I don't know if this is still the case, but giving the optimiser an easier time invites less bugs into your simulation...
In the case of FPGA designs, at least recently in my organization, we tend to just leave the busses as is and let the synthesis tool add the I/O pads. (We have not had to do anything exotic lately.) Then we use the vendor constraint files to place the pins in the right spots on the device and set drive strengths, etc. This has the pitfall that if the synthesis tool changes the way `busses' are rendered in the EDIF file, then the contstraints also have to change... :-(
--
regards, John
Mike Jarabek wrote:
> I am a bit confused by your statement about doing everything twice.
> Doesn't the synthesiser you are using take care of most of that anyhow?
>
> Can you post an example of how you might like vectored ports to be
> handled? Perhaps we can arrive at something that will work. What would
> be your ideal behaviour? Any ideas about how to handle errors?
>
> Mike
>
--------------------------------------------------
Mike Jarabek FPGA/ASIC Designer
http://www.istop.com/~mjarabek --------------------------------------------------