How to use xilinx specific features from Modelsim Designer 6.3a VHDL

Hi All,

I have started a test design in Modelsim Designer. I now have one entity written in VHDL and have placed this entity on a block diagram and added in- and out ports to the entity's signals. The entity simulates OK in a testbench and synthesis is OK (no constraints but 100MHz clock given).

Placing all signals on an I/O pin is easy with the PACE tool for 'normal' signals. But I can't figure out how to use a bi-directional differential buffer.

My entity has 3 signals for use with this buffer: in, out, output_enable And I want to connect these signals to a Bus-LVDS I/O buffer, but how? Preferrably also using the input synchronization.

Next problem is the clock input. There's a 50MHz oscillator connected to a clock input and I want to use the DCM to create a 100MHz (or even a

150MHz) global clock off of that.

I've searched the web and the Mentor and Xilinx sites, but found nothing yet. Any hints how to do this or where to look for more information?

The Modelsim manuals are reasonable upto and including the simulation, but fail after that. I know the synthesis and P&R are actually performed by Xilinx tools, but they could have made an effort taking you through the whole process as the offer complete integration. Or did I overlook some manual or tutorial?

Xilinx on the other hand, only document the ISE design route, so it seems I'm stuck somewhere in the middle.

First goal is to get the design running on the S3E starter kit.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

"Computers in the future may weigh no more than 1.5 tons."
 Click to see the full signature
Reply to
Stef
Loading thread data ...

Good work.

Your vhdl source and testbench is incomplete. Add code to infer and test the bidirectional buffer. related example:

formatting link
Pin numbers and I/O selection is best done at the back end, not it the source code or simulation.

Consider leaving it at 50 Mhz for the first proto. PLLs and DCMs are fussy vendor-specific black boxes.

-- Mike Treseler

Reply to
Mike Treseler

I have studied that page an came up with this:

entity bufbidir is port ( din : out std_logic; dout : in std_logic; doe : in std_logic; dpin : inout std_logic; clock : in std_logic ); end entity bufbidir;

architecture rtl of bufbidir is begin

bufbidir : process(clock) variable retimein_v : std_logic; begin if rising_edge(clock) then if doe = '1' then dpin

Reply to
Stef

...

I don't know your requirements. Run a sim and check the RTL viewer. This is how quartus sees your design:

formatting link

I would add the reset input. It costs nothing. It makes simulation much easier. It allows me to combine processes.

-- Mike Treseler

Reply to
Mike Treseler

I wanted an I/O buffer and that's what I got. I've read a lot here about retiming the input signal so I added that. Not sure about the output FF's though.

I have run it on an actual device, will do the simulation later. Can't find an RTL viewer in my version of ISE (still on 8.2i). Spent a good amount of time look through the floor planner and saw things simular to what you show below, but not nearly as nice.

That looks brilliant, exactly like I pictured it, thanks! But the question remains if this is a good way to handle I/O in an fpga. The signal is an asynchronous serial signal (uart like), so a little extra delay does not hurt at all.

On the other side of the "UART" I will need a bus interface to a cpu. Adding all that delay there slows down the interface, so I might need another approach.

I will have a rethink on the reset. But can you explain how it easies simulation? The way i see it, all these FF's will have clocked in their values after 2 clocks, so any reset value is gone after that anyway.

Sorry, but I can't understand that one at all, must be my inexperience in this field.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

"Computers in the future may weigh no more than 1.5 tons."
 Click to see the full signature
Reply to
Stef

They make it easier to meet timing in large processes. However I would never use a separate entity just to infer a buffer.

It might be worth your time to find it or upgrade. This is a valuable tool for learning and debugging.

A uart does not require tri-state pins at all.

-- Mike Treseler

Reply to
Mike Treseler

Never is such a big word. ;-) In this particular case I might keep the entity, as it is only a single bufffer at a rather important spot in the design. But in general, I think it will be less messy just to incorporate then in the existing processes.

Yes, I already downloaded 9.2i. I understand the value of the tool, I had been looking for something like your quartus output because I wanted to see what the tools did with myu code. I ended up using the floor planner as a poor substitute.

How would you handle the interface to an external cpu without tri- state buffers? If you meant for the serial pin only, that's why I quoted the word uart. Part of the design is a uart-like device. Serial transmission will use BLVDS, half-duplex over an single pair.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

"Computers in the future may weigh no more than 1.5 tons."
 Click to see the full signature
Reply to
Stef

Yes, of course. The customer/boss is always right.

Yes. It might make sense to have one design entity that converts the processor tristate data bus to separate read and write data buses on the fpga. Good luck.

-- Mike Treseler

Reply to
Mike Treseler

Yes. This is the design I have in mind (simplified)

CPUwrite ==> Mem ==> Processing ==> Serializer // \ BusInt SerInt \\ / CPUread

Reply to
Stef

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.