Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi Everybody, I want to investigate commercially available FPGAs to check out their reconfigurability options. I am basically trying to conduct a survey of the various FPGAs available to distinguish between them. Could you please give me pointers on: 1. The various points where FPGAs differ. (No: of functions available in the LUTs?, No: of times they can be re-configured?, Frequency?, Size(no: of gates)? any other.....) 2. Are there sites or papers I can refer to that explain the basics of the functionality. I am new to FPGA design, but have a Computer Architecture background. So I have a basic idea of how FPGAs work, but would like to dig deeper. 3. The most commonly used industry FPGAs. I have been browsing the threads in the newsgroup and have noticed that the Spartan II and the Virtex family are the most popular. Is that the case? or is that only because they are supported on Xilinx tools? Thank You. VenkatArticle: 45251
The distributed ram can be sync write and async read. So it'll cost ya 512 LUTs to make that ram portable to your previous design. You'll have to use Coregen to build that ram, Synplicity will not infer it. Regards "Arash Salarian" <arash.salarian@epfl.ch> wrote in message news:<3d3435b9$1@epflnews.epfl.ch>... > Hello, > > In my design, there is a FPGA to perform a large number of DSP functions. A > CPU will finally read the results from the FPGA. The problem is that FPGA's > output will be a frame of data with the size of 1024Kbytes. Now as the clock > of the CPU and FPGA are totally independent, in the previous version of the > design I used an Altera device and used a block of RAM, with synchronous > write (as the FPGA only needs to write the data) and asynchronous read (as > CPU only reads the data). > The problem is this approach is not portable to Xilinx devices as they do > not feature asynchronous RAM (as far as I know...) > So what's your suggestion to make this architecture portable? What should I > use instead of that block of RAM with sync. write and async. read? > (as the size of the RAM is not small, it's not wise to waste lots of CLBs in > a Xilinx device to emulate it....) > > Regards > ArashArticle: 45252
There are of course non-volatile FPGAs that are not open to attack of the configuration bit stream (e.g. Actel, Quicklogic, various CPLDs) Regards "Paul" <kimbledesign@eircom.net> wrote in message news:<plBX8.1654$zX3.1480@news.indigo.ie>... > Hi All, > Are there any security features in FPGA's that I can use to protect > software? > > regards > PaulArticle: 45253
Hi Venkat, > 2. Are there sites or papers I can refer to that explain the basics > of the functionality. I am new to FPGA design, but have a Computer > Architecture background. So I have a basic idea of how FPGAs work, but > would like to dig deeper. Scott Hauck's 1998 paper "The Roles of FPGAs in Reprogrammable Systems" is a good place to start (http://citeseer.nj.nec.com/hauck98roles.html) as is Brown & Rose's "Architecture of FPGAs and CPLDs: A Tutorial" (http://klabs.org/richcontent/Tutorial/fpga/Toronto_tutorial.pdf). Cheers, SteveArticle: 45254
Mike Rosing wrote (on 7/13/2002):
Wow, two days before the quote you were replying to :-)
> I'm a newbie at this: how do I go about specifying Xilinx primitives in
> my code? I'd like to grab hold of the LUT/RAM/shift reg block. It
> seems like I should be able to do both random access of any bit or
> shift the whole thing depending on where I am in an algorithm. I'd also
> like to grab the multiplier in the V2 parts.
For simulation, you need to specify the library:
--synopsys translate_off;
library unisim;
use unisim.vcomponents.RAMB4_S16;
--synopsys translate_on;
Then in the architecture section:
architecture synth of mydesign is
component BUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
-- XST black box declaration
attribute box_type : string;
attribute box_type of BUFG: component is "black_box";
...
begin
aclk_bufg: BUFG
port map(
I => ACLK_DBL,
O => ACLK_DBLG
);
--
My real email is akamail.com@dclark (or something like that).
Article: 45255Jon, What are your timing margins like for setup/hold? Changing the loading on a bus can make a barely working design, fail; perhaps you've done this. Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3D32E643.D5BD9172@xilinx.com>... > Jon, > > This is a classic signal integrity SI) problem. > > The clock frequency isn't the issue, it is the rise and fall times, which > are incredibly fast (< 1 ns). > > Thus with a 10 Gs scope with 3 GHz fet probes, you might be able to see > what is happening (impedance mis-match). Seeing it won't help you though. > > I would simulate your PCB and drivers and receivers using IBIS models, and > the extracted pcb trace impedances and other transmission line > characteristics using an IBIS simulator (Hyperlynx, Cadence SpectraQuest, > Mentor, Innoveda, etc). This way you can layout the board, place > terminations, adjust the impedances of the lines, etc. > > The idea is that if you simulate it, you can fix it before you build the > boards, and save spinning the pcb due to SI issues three to seven times > (typical of what happens if you don't simulate!). > > When the boss complains about the price of the simulator, I think the idea > of no more board spins for SI, and no more wasted time playing with > unreliable bandaids (ie caps) will win the argument forever. Innoveda's > Hyperlynx costs less than spinning the pcb even once. > > Austin > > Jon Nicoll wrote: > > > Hello there > > I'm working on getting some FPGA images into a daisy chain of > > three Spartan 250s. This is loaded in byte serial mode via the > > parallel port pins of a Motorola coldfire processor. > > > > This is a relatively simple extension of the sort of loading we've > > done successfully in the past (eg. we've loading two devices, not > > three), but we've had a _lot_ of trouble getting this running on our > > new hardware. > > > > Our current fix is to put a small cap (22pF) from the CLK line to > > ground. We cannot see the effect of this cap on the 'scope, but it > > definitely makes a difference to the loading. > > > > Our concern is that even without the cap all the timing constraints > > for programming the Xilinx parts appear to be being met. the CLK line > > is slew-rate limited to ~10nS, and there appears to be no coupling > > between the CLK and PROGRAM pins. We believe that we are ensuring that > > the various details mentioned in app notes etc. are being adhered to. > > > > The board is very well decoupled and we are confident of the DC > > supplies to the processor and FPGAs. The general purpose pins on the > > Motorola Parallel port are supposedly well capable of driving these > > loads, and we're not running at any great speed (CLK about 1usec high, > > 4usec low). > > > > My question is - is there any 'lore' out there about programming > > Xilinx parts, or Spartan 2s in particular, that might shed light on > > this problem? Any pointers very gratefully received! > > > > Thanks > > Jon Nicoll > > Alembis Ltd. > > --Article: 45256
"Helmut Sennewald" <HelmutSennewald@t-online.de> schrieb im Newsbeitrag news:agct89$uvh$05$1@news.t-online.com... > Hello, > we had a problem with the clockbuffer in a Spartan-XCS40XL. > The state machines sometimes went crazy. It is a one hot design. > By accident, we fixed the problem by changing the clock buffer > from the left upper corner to the right lower corner of the chip. > We have used only one clocknet with 20Mhz for all flipflops. > > Now we have transferred the design from XL to Spartan-2E. The > state machines again behave sometimes crazy. > I guess we have 1000 or more flipflops on that clock net. > The power supply voltages are ok. ... > Any idea what is going wrong? > Hello to all readers, the reason for the bad behaviour was the slow rise and fall time of our clock signal. I had used a RC-Filter in the clock line to reduce possible EMI(electro magnetic interference). The time constant including load capacitance was about 10ns. After removing the filter, the FPGA has been working perfectly. Hopefully my answer will help others to avoid that mistake. Best Regards HelmutArticle: 45257
What frame rate/resolution are you targeting? One of the available MPEG2 ASICs will give you the lowest power solution. I'm not sure if a DSP can do real time MPEG2 with motion prediction and all that. It would certainly be the highest power. The FPGA would be somewhere in the middle and give you the luxury of a custom solution. And as far are reusing DSP code, no way, especially if its been tuned for the particular DSP you're using. The fact that you know the algorithms because you wrote the C code will be great help as you recode your design for hardware implimentation. Regards "paul hill" <paul.hill@bristol.ac.uk> wrote in message news:<aguabf$j5c$1@helle.btinternet.com>... > Hi, > > I'm currently trying to spec a project that needs to do some serious video > processing (mpeg2 encoding or similar) in a mobile (wearable) environment. > i.e. battery powered. > > Does anyone have any opinion on what dsp platform would be suitable. People > have been talking about xilinx chips or something similar. However, I'm > most familiar with DSP programming on ti processors (such as C67xx) but > would an implementation using ti processors take too much power and be too > slow. > > Ideally I would like to reuse the c-code that I have already for the mpeg2 > codec but with xilinx chips this would not be possible. > > Any ideas anyone? > > Paul HillArticle: 45258
Jonathan, Response below. On Wed, 17 Jul 2002 09:24:01 +0100, "Jonathan Bromley" <jonathan.bromley@doulos.com> wrote: >> What are good designs for mapping registers in an FPGA >> into a microprocessors address space, to operate >> like asynchronous >> ram in terms of bus timing. > >> The read part seems pretty easy >[...] >agreed, as long as your FPGA can meet the bus cycle timing of >the processor bus. > >> I guess there is a concern of >> metastability when a status bit is changing during a read, is >> this a problem I should be concerned with? > >Yes. But unless the read cycle is very fast, it's probably >OK to have a bank of registers for the read data and clock >that read register on the leading edge of the read strobe. >The CPU will read it on the trailing edge, by which time >all but the most pernicious metastability trouble should >have settled down. Keep these "read cycle buffer" registers >very closely coupled with the output and strobe pads so that >all the timing is nice and predictable. Thanks for the tip. I hadn't thought of that, it is an interesting twist on the synchronizing flip-flop idea. > >> For writing the situation seems more complicated. > >Agreed; and I agree with you that it's not easy to find >useful reference material. > >> because the FPGA clock is slower than the memory bus, such >> that it would be >> possible to do multiple writes per FPGA clock cycle. > >Eeek! > >Can't you get the FPGA to introduce wait states into the >read cycle? I could configure the micro to put wait states in the memory region, except I need the bus to read at full speed out of a fifo that is in the FPGA. And naturally, the signal to insert wait states is not brought out to the FPGA. >> I've heard that FPGA have to build latches up from >> combinatorial logic, and that their performance is quite poor? > >Yes, they are usually best avoided. > >> The Timing diagrams for the microprocessors I've looked at >> make it look like >> I can use the \WR signal as a rising edge clock, and then >> decode the \CS and >> ADDR lines for an ENABLE signal for D-FF registers. Is this a good >> technique? > >It's OK as a method to write data from the bus into a bunch >of registers just inside the FPGA - typically registers in the >FPGA's I/O pads. This doesn't help with the multiple writes >problem, though. Are you certain there is still a problem? I think so long as I don't care about the results if there are multiple write then all I need is a synchronizer that can capture pulses shorter than one clock cycle. I've done this by having a FF that is triggered on the rising edge of the write signal, and has D_a = (the decoded chip_select) + Q_a. the output of this flip flop is then feed into a chain of two synchronizing flip flops. The original pulse catching flip flop is disabled when the second flip flops output is high. here is the basic idea in verilog: always @ (posedge wr_n or posedge clr) begin if (clr) ff1 <= 0; else if (cs || ff1) ff1 <= 1; end always @ (posedge clk) begin ff2 <= ff1; ff3 <= ff2; end assign clr = ff3; assign output = ff3 & ~ff2; // for one cycle pulse I think this is a pretty good design, the wr_n is already on one of the FPGA's global clock buses. The basic scheme is the data is captured in a register on the wr_n stobe's rising edge then a few fpga clock cycles later a pulse is generated alerting another module that new data is available. As I said in my previous post, I can ensure that the CPU never writes to the register too quickly. I was just using the double write to illustrate that the cpu memory bus was significantly faster than the FPGA's clock. > >> I can also see how one could use the embedded memory in >> asynch mode to >> implement the registers. This would certainly be a very low overhead >> technique for the bus side, but would make it more >> complicated accessing the >> data inside the FPGA. I would probably have extra logic on >> the back that >> would take the synchronized write signal and use it to read >> the written >> memory to an internal register to hold for access by other >> modules in the >> design. > >If you have a lot of memory mapped writeable registers that >are used only occasionally inside the FPGA (e.g. for configuration) >this seems like a good way to do it. Although, most often I want a variety of status, command, and configuration registers. >Sorry I can't be much more helpful - the same issue has caused >me some heartache in the past. It's all soooo much easier if >the FPGA and CPU/bus can share a clock. It is always good to get some feedback that I didn't overlook anything blatantly obvious. I will go ahead and add the synchronizing read FFs, because I was a bit uncomfortable with the potential for violating the CPU bus's setup and hold time requirements. Next time I will make a synchronous CPU bus a design requirement. Joey NelsonArticle: 45259
Hello,
I am trying to obtain an ALTERA PLMG5192(A) programming adapter needed
to program an EPM5192GC. ALTERA has transferred its 5000 series parts
to Cypress, therefore no longer supports the 5000 series programming
adapters. If you have knowledge of a PLMG5192 which I can purchase
please contact me.
Thanks, Craig McClure
Fermilab
PO Box 500
Batavia, IL
email:mcclure@fnal.gov
Article: 45260Hi Kevin, Kevin Brace wrote: > > Erik wrote: > > > > Real? I can become from Insight a complett SpartanII-Development-Kit for this Price but i can't use it. > > Are you using Insight Electronics Spartan-II PCI Development Kit > to do 66MHz PCI? No, Insight can me not say the speed grade of the used chip. On the home-page stay "speed 5", in the comercial-info-pdf-file "speed 6" and in the technikal users-guide stay "speed 6" in the text and a graphic meens an completly other chip-typ. > Whether it is the older PCI kit (The one that uses XC2S150-5CPQ208) or > the newer PCI kit (The one that uses XC2S200-5CFG456), I doubt you will > meet 66MHz PCI's timings assuming that you want to do zero wait state > transfer, considering that they use the slower -5 part, not the faster > -6 part. > Plus, both cards don't have the M66EN pin needed for a motherboard to > detect the presence of a 66MHz PCI card. My motherboard don't use the M66EN pin, the trick is an undocumented jumper for the clock-ratio betwen the CPU-FSB and the PCI-clock. For older CPU's (with slower FSB) is it on 2:1 and for faster CPU's is it on 3:1 or 4:1. Normaly, if somebody change the FSB-clock, he must configurate many jumpers. But 2 of this are for the PCI-clock-ratio and, if you know it, you can modify the PCI-clock. The chipset can not check the legality of the jumpersettings and it works stable at 50MHz. I have test it with a 1GBit ethernet-card in the IT-department at my job (my admin is my friend). Normaly, at a board with real 66MHz-3.3V-PCI, the 66M-Bit (Bit 5) in the statusregister of this card is set. But on my board this Bit is not set and the carddriver say 'run on 33MHz' with a real clock at 50MHz (checked with an PCI-benchmark) and with 5V. > > The original Virtex is the fastest Chip that will do 5V-PCI. > > I need it for a speazial interface-card with a high bandwitch for communication. > > For the bandwitch, that i need, i must overclock the PCI-bus and a SpartanII is not fast enough for 50MHz-PCI. > > I have a mainboard with a configuration-option for clock-ratio betwen frontside-bus and pci-bus. > > The Virtex will do 66MHz-PCI and is the best solution for my problem > > (better clock-DLL, faster slices and faster io-buffers). > > > > > First of all, to do a universal PCI card (A PCI card that > supports both 3.3V and 5V PCI.), you need to have a chip that detects > +VIO pin voltage and two bitstream images. > Secondly, although no official timing specification for 50MHz PCI > exists, according to PCI Specification 2.2 Page 236, unofficially the > Tsu and Tval remain same as 66MHz PCI (3ns and 6ns respectively.), which > means that the difficulty meeting timings is as bad as 66MHz PCI. > Thirdly, I am not sure if you are using LogiCORE PCI, licensed a PCI IP > core from a third-party IP core developer, or did your own PCI IP core, > but unless you licensed LogiCORE PCI, I will say the chance of meeting > 66MHz PCI timings is pretty slim even if you used Virtex-6 or > Spartan-II-6. I will create my own PCI-core. > The thing is that, Xilinx has an upper hand compared to a third-party > developer when it comes to 66MHz PCI because they know how to use two > crucial undocumented (secret) features of Virtex silicon (PCILOGIC and > BITGEN's /Gclkdel option.). > Someone before me has figured out how to instantiate PCILOGIC from > user's design (i.e., By instantiating a blackbox of PCILOGIC in HDL > code.), so based on that information, I attached PCILOGIC to my PCI IP > core, and PCILOGIC worked fine with my PCI IP core, but /Gclkdel is much > harder to use considering that Static Timing Analyzer is not aware of > BITGEN's /Gclkdel option. > Still, one Xilinx employee posted a way to figure out how /Gclkdel > option works by measuring the delay with an oscilloscope, but it doesn't > help me because I don't have an oscilloscope. > > > > > > Its an privat project and then i buy a SpartanII-PCI-Kit and at the middle of the work > > i see the Spartan is not fast enough i have lost my money. > > In my opinion is the better way i have at the end a working project with a littel bit reserve. > > > > Erik > > > Is Spartan-II-6 that slower than Virtex-6? > Comparing a 4-input LUT delay, it's about the same (about 0.6ns) Yes, its correct, but the most other timings, includet the IO-timings, are differnt. > , although I have never targeted Virtex-6 (Because ISE WebPACK doesn't > support Virtex.) Xilinx say "Virtex Series up to 300K gates" : http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack I have downloadet this version. > , so I am not sure how Virtex-6 fares. > Although it cannot not do 66MHz PCI, Insight Electronics Spartan-II PCI > Development Kit is a fine 33MHz PCI card, so if you can put it up on an > auction site, I am sure someone will buy it. > > > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) thanx for your answer! ErikArticle: 45261
thanx for this tip. Erik "Jay" wrote : > If its a limited quantity kind of project, and your time is cheaper > than the parts, you can get some great deals on E-bay. For example, > right now there are 18 XCV300E going at $46 (10am PST 7/16/02). > > Regards > > <vikinger@uni.de> wrote in message news:<ah0gth$bu7$01$1@news.t-online.com>... > > Hello at all, > > > > i need 4 Xilinx XCV300-6PQ240C or XCV300-6BG352C. > > Heer in germany say me a person in a regional dealer it cost 328,00 EUR (~ $300)! For ONE! > > I think its to many. > > Who kann me say that is the real price for a this FPGA and where can i buy it. > > > > Bye > > Erik.Article: 45262
Ray Andraka wrote: > > Arash Salarian wrote: > > >>"jetmarc" <jetmarc@hotmail.com> wrote in message >>news:af3f5bb5.0207161704.2f82f19f@posting.google.com... >> >>>>I'm in doubt that you'd succeed to find such a tool. Generally as the >>>> >>exact >> >>>>configuration of the LUTs and switch boxes inside a FPGA device is kept >>>>secret; there is no 3rd party place and route tool for any FPGA family. >>>> >>>Atmel gives away this type of information under NDA, even when you're not >>>a tool maker. >>> >>Yet I don't think such information is enough to write a Place and route >>software. As you see, there is no such tool as a 3rd party Place and route >>in the market at all (yeah, but maybe for very old devices like MAX5000....) >> > > Atmel does give you enough info to route the design under the NDA. We used it a > while back for the 6K devices to do some generators for some placed and routed > DSP macros. For a general purpose router, there is so much more architecture > specific stuff than just the bitstream coding to concern yourself with. It is > not a trivial effort by any stretch of the imagination. For that reason, you > are not likely to find 3rd party routers for devices that are not really > mainstream to begin with. > > Amplify is not a router, It does placement using the mechanisms for externally > applied floorplanning provided by the FPGA tools. You still need to run the > design through the tool to get the full placement as well as the route and > bitstream. Sorry Ray, old data. The more recent versions of Amplify perform a full placement for all instances in the regions you make as part of the optimization flow. We also do detailed estimation of the routing as part of the placement so we get the timing right. There is no current interface to pass routing forward. You are correct about having to run the design through the Xilinx P&R tools to finish the placement of instances outside of the regions and to do routing. > > >> >>Amplify, as reffered to by Ken is not a place and route tool, but rather a >>"physical optimizer" as it calls itself. It helps the vendors place and >>route tool a lot in terms of finding much better placement but has nothing >>to do with routing phase (but maybe just to ensure a routing is possible >>...). Again in this case I doubt that Synplicity has ever had access to all >>detials of Virtex series configuration internals... >> >>Best Regards >>Arash >> > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > > >Article: 45263
Erik wrote:
>
> Hi Kevin,
>
> No, Insight can me not say the speed grade of the used chip. On the home-page
> stay "speed 5", in the comercial-info-pdf-file "speed 6" and in the technikal
> users-guide stay "speed 6" in the text and a graphic meens an completly other
> chip-typ.
>
I also noticed the speed grade discrepancy you are talking
about.
Because I own the older Spartan-II PCI Development Kit, I have access to
their reference design center, so I downloaded reference design files
related to the newer Spartan-II PCI.
It turns out, the board uses the slower speed grade -5, which has almost
no chance of meeting 66MHz PCI's Tsu < 3ns requirement, unless one wait
cycle is inserted for every transfers.
Also, the newer Spartan-II PCI card doesn't have the required M66EN pin
needed to support 66MHz PCI.
I don't know how much it costs, but Nallatech
(http://www.nallatech.com) sells a Virtex XCV300-based PCI card.
Xilinx used to resell it as part of a development kit.
> My motherboard don't use the M66EN pin, the trick is an undocumented jumper
> for the clock-ratio betwen the CPU-FSB and the PCI-clock. For older CPU's
> (with slower FSB) is it on 2:1 and for faster CPU's is it on 3:1 or 4:1.
> Normaly, if somebody change the FSB-clock, he must configurate many jumpers.
> But 2 of this are for the PCI-clock-ratio and, if you know it, you can modify
> the PCI-clock. The chipset can not check the legality of the jumpersettings
> and it works stable at 50MHz. I have test it with a 1GBit ethernet-card in the
> IT-department at my job (my admin is my friend). Normaly, at a board with real
> 66MHz-3.3V-PCI, the 66M-Bit (Bit 5) in the statusregister of this card is set.
> But on my board this Bit is not set and the carddriver say 'run on 33MHz' with
> a real clock at 50MHz (checked with an PCI-benchmark) and with 5V.
>
Since 5V PCI is not intended to run above 33MHz, I will guess
that most cards will likely fail at 50MHz.
Also you should be aware that Virtex/Spartan-II's 5V PCI I/O pads are a
lot slower than their 3.3V 66MHz PCI I/O pads.
> I will create my own PCI-core.
>
First of all, you should be aware that Opencores.org has a PCI
IP core available for free.
If that doesn't work for you, and you are going to develop your own PCI
IP core, I will suggest that you first try to meet 33MHz PCI's timings
(Tsu < 7ns, Tval < 11ns, Th <= 0ns.).
Although it might seem like 33MHz is not a big deal, if you don't have
much experience dealing with FPGAs, you will likely have hard time
meeting timings, especially the Tsu < 7ns part.
You shouldn't be surprised to spend 6 months to 1 year on developing a
PCI IP core because that's about how much it took more than a year to do
my PCI IP core from scratch not knowing anything about HDL or FPGAs.
It is quite possible that you might have to spend a few months just
trying to meet the setup time (Tsu < 7ns).
A lot of people don't want to go through that, so that's the reason they
license a PCI IP core.
Since I went through the whole process of developing a PCI IP core
myself, I will suggest you do,
1) Use Floorplanner to reduce routing delay. If you designed your PCI IP
core correctly, you shouldn't have to use Floorplanner for 33MHz PCI
(Automatic P&R should get timing closure. My PCI IP core gets timing
closure for 33MHz PCI with only automatic P&R.), but it is a must for
66MHz PCI.
2) Don't bother with expensive synthesis tools like Synplify. It's just
not worth the price tag ($9,000 I am told.). ISE WebPACK and XST (Xilinx
Synthesis Technology. A free synthesis tool that comes with ISE
WebPACK.) is absolutely fine for developing a PCI IP core. Don't blame
the synthesis tool for timing issues. Simulate your PCI IP core
adequately before firing it up. If you simulate it adequately, it should
work fine the first time.
3) Separate datapath (AD[31:0] and C/BE#[3:0]) from target or master
state machine.
4) Use Address/Data Stepping. A must for 66MHz PCI.
5) Use PCILOGIC to control AD[31:0] output FFs. Another must for 66MHz
PCI.
6) Know how FFs with CE (Clock Enable) inputs (FDCE) work. Use CE input
to control AD[31:0] output FFs.
7) Keep levels of LUT as low as possible for unregistered control
signals to a FF paths. It should be at or below 3 levels of 4-input LUT
for PCI control signals (FRAME#, IRDY#, DEVSEL#, etc.) as much as
possible, and 1 level (When using PCILOGIC) or 2 levels (2 levels of
4-input LUT) for datapath (AD[31:0]).
8) Turn your PCI IP core into an I/O padless EDIF netlist, and
instantiate it from your backend logic. That should save you a lot of
synthesis time in the long run. Instantiate I/O pads and tri-state
buffers from the backend design.
9) For 66MHz PCI, you need to artificially increase global clock buffer
delay so that you have more setup time. Use BITGEN's /Gclkdel or connect
two adjacent GCLKBUFs in series to create more delay.
> Xilinx say "Virtex Series up to 300K gates" :
> http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack
> I have downloadet this version.
>
>
> thanx for your answer!
> Erik
The catch is, even though Xilinx says that, ISE WebPACK doesn't
actually support Virtex-I (0.22u part), although it does support
Virtex-E (0.18u part) up to 300K part and Spartan-II.
If you want Virtex-I support, I believe you will have to pay for ISE
BASE-X which costs $700.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 45264Mike Rosing wrote: > Duane Clark wrote: > > [nice details snipped] > > OK, that actually makes sense. Will it work just as well for synthisis > as for simulation? Yep, the black box declaration tells XST to just put a placeholder into the edif/ngc file (I think it is the ngc file that XST builds). Then ngdbuild will fill it in correctly. The same process is used for any other non primitive modules supplied as edif files. The edif file just needs to be where ngdbuild can find it. I notice that Xilinx has some modules on their website, such as a UART, available only in edif form. -- My real email is akamail.com@dclark (or something like that).Article: 45265
I have a design with a spartan2e that I cannot get to release the done signal. the configuration is m0 and m1 =logic 0 and m2=logic 1 reset/oe connects to init_bar done to ce din and cclk to data and clk also the clk does not stop I am using the standard default configuration options. Any help? Thanks, TheronArticle: 45266
Ken McElvain wrote: > There is no current interface to pass routing forward. I followed the directions in Philip Freidin's reply in the thread on this newsgroup "Xilinx XAPP622: Info on ROUTE constraint?" on July 2nd (original question July 1st) and got my routing to work beautifully. The routing information can be communicated through a series of explicit strings. What the strings mean isn't obvious but the fact that there is a way to pass routing information through constraints files is established. Efficiencies and meanings are a different issue. I was happy to get a couple critical routes hand-tuned for best performance.Article: 45267
"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message news:<B1KKA1aLCHA.4944@lucy.doulos.com>... > > -----Original Message----- > > From: Bill Sloman [mailto:bill.sloman@ieee.org] > > Subject: Re: LVDS interface cable recommendation sought > > And what, may I ask, brings you here? I thought you > didn't hold with all this new-fangled programmable logic > stuff ? :-) Cross-posting. And its not that I don't hold with programmable logic - I've done some neat tricks with the ICT PA7024, and some perfectly horrible rescue jobs using them to clean up botched 22V10's - but I suffer from the usual fate of those who are good with analog, which is that everybody gives the neat digital stuff to the wet-behind-the-ears new graduates, who can't handle analog. This is a complete Xilinx freeby programing set-up on my computer at work, which I keep up to date in the hope that I can find a problem on which I can use it, but nothing has come up so far. We are thinking about commercialise an interesting research set-up, and the prototype does incorporate a CoolRunner chip, but that is as close as I've come. ----- Bill Sloman, NijmegenArticle: 45268
Apologies - your mentions were with respect to Atmel only and not about the Amplify capabilities with Xilinx? The Xilinx ROUTE constraint came as a complete surprise to me and I'm very happy to have found it. I figured even the industry best have probably had this information slip by. Ken McElvain wrote: > Ray Andraka wrote: > > > > > Arash Salarian wrote: > > > > > >>"jetmarc" <jetmarc@hotmail.com> wrote in message > >>news:af3f5bb5.0207161704.2f82f19f@posting.google.com... > >> > >>>>I'm in doubt that you'd succeed to find such a tool. Generally as the > >>>> > >>exact > >> > >>>>configuration of the LUTs and switch boxes inside a FPGA device is kept > >>>>secret; there is no 3rd party place and route tool for any FPGA family. > >>>> > >>>Atmel gives away this type of information under NDA, even when you're not > >>>a tool maker. > >>> > >>Yet I don't think such information is enough to write a Place and route > >>software. As you see, there is no such tool as a 3rd party Place and route > >>in the market at all (yeah, but maybe for very old devices like MAX5000....) > >> > > > > Atmel does give you enough info to route the design under the NDA. We used it a > > while back for the 6K devices to do some generators for some placed and routed > > DSP macros. For a general purpose router, there is so much more architecture > > specific stuff than just the bitstream coding to concern yourself with. It is > > not a trivial effort by any stretch of the imagination. For that reason, you > > are not likely to find 3rd party routers for devices that are not really > > mainstream to begin with. > > > > Amplify is not a router, It does placement using the mechanisms for externally > > applied floorplanning provided by the FPGA tools. You still need to run the > > design through the tool to get the full placement as well as the route and > > bitstream. > > Sorry Ray, old data. The more recent versions of Amplify perform a full > placement for all instances in the regions you make as part of the > optimization flow. We also do detailed estimation of the routing as > part of the placement so we get the timing right. There is no current > interface to pass routing forward. You are correct about having to run > the design through the Xilinx P&R tools to finish the placement of > instances outside of the regions and to do routing. > > > > > > >> > >>Amplify, as reffered to by Ken is not a place and route tool, but rather a > >>"physical optimizer" as it calls itself. It helps the vendors place and > >>route tool a lot in terms of finding much better placement but has nothing > >>to do with routing phase (but maybe just to ensure a routing is possible > >>...). Again in this case I doubt that Synplicity has ever had access to all > >>detials of Virtex series configuration internals... > >> > >>Best Regards > >>Arash > >> > > > > -- > > --Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com > > > > "They that give up essential liberty to obtain a little > > temporary safety deserve neither liberty nor safety." > > -Benjamin Franklin, 1759 > > > > > >Article: 45269
In article <ah0i0g$6ku$06$1@news.t-online.com>, Alexander Weiss wrote: >Hi all, >anybody knows a source for a configuration software for the HP16500B / >HP16510 logic analyzer, which displays JTAG State Information and JTAG State >Mnemonics? > >Alexander Personally I upload it to a unix box and process it there. One can decode one's private instructions and data fields too that way. It wouldn't surprise me if Agilent sells a JTAG disassembler for the HP16500, along the same lines as their microprocessor disassembler packages. Have you asked them? An alternative approach would be to implement the TAP in a small PAL, and feed its state vector into the HP16500B. Then you could use the user-defined mnemonics to display it. Mike.Article: 45270
I would look at the data output from the PROM = Din of the FPGA and check whether there is a steady stream of data. I assume you have the right RESET polarity ( reset_bar ) Peter Alfke ================================= Theron Hicks wrote: > I have a design with a spartan2e that I cannot get to release the done > signal. > > the configuration is m0 and m1 =logic 0 and m2=logic 1 > > reset/oe connects to init_bar > done to ce > din and cclk to data and clk > > also the clk does not stop > > I am using the standard default configuration options. > > Any help? > > Thanks, > TheronArticle: 45271
Hi --
I solved my own problem. Looks like I need to do a master reset
anyways -- even if there is data loaded into the RAM initially. Makes
no sense to me. I'm not sure how you would ever access those initial
values if you have to reset before the thing will work. Thank
goodness I don't need initial values.
Cheers,
John
"John Hovell" <jhovell@yahoo.com> wrote in message news:<ah35u3$dvd$1@usenet.Stanford.EDU>...
> Hello all --
>
> I downloaded a Verilog template for a Spartan II common-clock FIFO using
> Block RAM from Xilinx from
> ftp://ftp.xilinx.com/pub/applications/xapp/xapp175.zip .
> I am using Xilinx Web Pack 4.2 Service Pack 2, and designing for a Spartan
> IIe.
>
> I also downloaded the latest version of the xilinxcore_ver libraries and
> installed them in the correct directory in the ModelSim directory.
>
> Still, when I simulate fifoctlr_cc.v (the file given from the ZIP above,
> source code given in-line following message), all the outputs of the
> bram4_s8_s8 primative are X's (unknown) in ModelSim.
>
> I corrected a lot of warnings ModelSim was complaining about (not all the
> outputs from the bram4_s8_s8 were connected (I connected one to a dummy
> net); I wasn't using INIT_00, INIT_01, etc for initial values, and gave it
> dummy values using the workaround for Synopsys described at
> http://www.xilinx.com/xapp/xapp130.pdf )... but no luck. Then I tried
> temporarily removing extra stuff like the clock buffer or some surrounding
> control logic and simulating again ... still ... no luck :-(. So ModelSim
> gives me no errors, but all I get out of the bram4_s8_s8 are X's!
> Obviously, I have assigned input values to all my inputs in ModelSim. I've
> also simulated non-block RAM modules from other projects and they work fine.
> I also realize since this is a memory, theoretically the values are
> *unknown* to start with, but I tried it with an initialization vector... and
> all values are still X's... even ones that should be determinable like
> "empty" and "full."
>
> I saw one earlier posting about needing to change a line in the bram4_s8_s8
> Verilog model and recompiling the library for ModelSim but it was for a
> different version of ModelSim and WebPack... I thought I would ask first --
> it seems a lot of people would want to simulate block RAM in Verilog
> projects, and this was the simplest case I could come up with, and it
> doesn't work :-(.
>
> Any help/pointers/info, etc greatly appreciated :-).
>
> Cheers,
> John
>
> /***********************************************************************\
> * *
> * Module : fifoctlr_cc.v Last Update: 12/13/99 *
> * *
> * Description : FIFO controller top level. *
> * Implements a 511x8 FIFO with common read/write clocks. *
> * *
> * The following Verilog code implements a 511x8 FIFO in a Spartan-II *
> * device. The inputs are a Clock, a Read Enable, a Write Enable, *
> * Write Data, and a FIFO_gsr signal as an initial reset. The outputs *
> * are Read Data, Full, Empty, and the FIFOcount outputs, which *
> * indicate roughly how full the FIFO is. *
> * *
> \***********************************************************************/
>
> `timescale 1ns / 10ps
>
> `define DATA_WIDTH 7:0
> `define ADDR_WIDTH 8:0
>
> module fifoctlr_cc (clock_in, read_enable_in, write_enable_in,
> write_data_in, fifo_gsr_in, read_data_out,
> full_out, empty_out, fifocount_out );
>
> input clock_in, read_enable_in, write_enable_in, fifo_gsr_in;
> input [`DATA_WIDTH] write_data_in;
> output [`DATA_WIDTH] read_data_out;
> output full_out, empty_out;
> output [3:0] fifocount_out;
>
> wire read_enable = read_enable_in;
> wire write_enable = write_enable_in;
> wire fifo_gsr = fifo_gsr_in;
> wire [`DATA_WIDTH] write_data = write_data_in;
> wire [`DATA_WIDTH] read_data;
> assign read_data_out = read_data;
> reg full, empty;
> assign full_out = full;
> assign empty_out = empty;
>
> reg [`ADDR_WIDTH] read_addr, write_addr, fcounter;
>
> wire read_allow, write_allow;
>
> assign read_allow = (read_enable && ! empty);
> assign write_allow = (write_enable && ! full);
>
> wire gnd = 0;
> wire pwr = 1;
>
> /**********************************************************************\
> * *
> * A global buffer is instantianted to avoid skew problems. *
> * *
> \**********************************************************************/
>
> BUFGP gclk1 (.I(clock_in), .O(clock));
>
> /**********************************************************************\
> * *
> * Block RAM instantiation for FIFO. Module is 512x8, of which one *
> * address location is sacrificed for the overall speed of the design. *
> * *
> \**********************************************************************/
>
> RAMB4_S8_S8 bram1 ( .ADDRA(read_addr), .ADDRB(write_addr), .DIB(write_data),
> .DIA({gnd, gnd, gnd, gnd, gnd, gnd, gnd, gnd}),
> .WEA(gnd), .WEB(write_allow), .CLKA(clock),
> .CLKB(clock), .RSTA(gnd), .RSTB(gnd),
> .ENA(read_allow), .ENB(pwr), .DOA(read_data) );
>
> /***********************************************************\
> * *
> * Empty flag is set on fifo_gsr (initial), or when on the *
> * next clock cycle, Write Enable is low, and either the *
> * FIFOcount is equal to 0, or it is equal to 1 and Read *
> * Enable is high (about to go Empty). *
> * *
> \***********************************************************/
>
> always @(posedge clock or posedge fifo_gsr)
> if (fifo_gsr) empty <= 1;
> else empty <= (! write_enable && (fcounter[8:1] == 8'h0) &&
> ((fcounter[0] == 0) || read_enable));
>
> /***********************************************************\
> * *
> * Full flag is set on fifo_gsr (but it is cleared on the *
> * first valid clock edge after fifo_gsr is removed), or *
> * when on the next clock cycle, Read Enable is low, and *
> * either the FIFOcount is equal to 1FF (hex), or it is *
> * equal to 1FE and the Write Enable is high (about to go *
> * Full). *
> * *
> \***********************************************************/
>
> always @(posedge clock or posedge fifo_gsr)
> if (fifo_gsr) full <= 1;
> else full <= (! read_enable && (fcounter[8:1] == 8'hFF) &&
> ((fcounter[0] == 1) || write_enable));
>
> /************************************************************\
> * *
> * Generation of Read and Write address pointers. They use *
> * LFSR counters, which are very fast. Because of the *
> * nature of LFSRs, one address is sacrificed. *
> * *
> \************************************************************/
>
> wire read_linearfeedback, write_linearfeedback;
>
> assign read_linearfeedback = ! (read_addr[8] ^ read_addr[4]);
> assign write_linearfeedback = ! (write_addr[8] ^ write_addr[4]);
>
> always @(posedge clock or posedge fifo_gsr)
> if (fifo_gsr) read_addr <= 'h0;
> else if (read_allow)
> read_addr <= { read_addr[7], read_addr[6], read_addr[5],
> read_addr[4], read_addr[3], read_addr[2],
> read_addr[1], read_addr[0], read_linearfeedback };
>
> always @(posedge clock or posedge fifo_gsr)
> if (fifo_gsr) write_addr <= 'h0;
> else if (write_allow)
> write_addr <= { write_addr[7], write_addr[6], write_addr[5],
> write_addr[4], write_addr[3], write_addr[2],
> write_addr[1], write_addr[0], write_linearfeedback };
>
> /************************************************************\
> * *
> * Generation of FIFOcount outputs. Used to determine how *
> * full FIFO is, based on a counter that keeps track of how *
> * many words are in the FIFO. Also used to generate Full *
> * and Empty flags. Only the upper four bits of the counter *
> * are sent outside the module. *
> * *
> \************************************************************/
>
> always @(posedge clock or posedge fifo_gsr)
> if (fifo_gsr) fcounter <= 'h0;
> else if ((! read_allow && write_allow) || (read_allow && ! write_allow))
> begin
> if (write_allow) fcounter <= fcounter + 1;
> else fcounter <= fcounter - 1;
> end
>
> assign fifocount_out = fcounter[8:5];
>
> endmodule
Article: 45272
Jay wrote:
> The distributed ram can be sync write and async read. So it'll cost
> ya 512 LUTs to make that ram portable to your previous design. You'll
> have to use Coregen to build that ram, Synplicity will not infer it.
>
> Regards
>
Never had any problem with Synplify inferring Xilinx distributed (SelectRAM instead of
BlockSelectRAM) RAMs. Here's a template for a 128x8 RAM with separate write (sync) and read (async)
port:
input clk, we;
input [6:0] rd_addr, wr_addr;
input [7:0] di;
output do;
reg [7:0] ram[127:0];
always @(posedge clk)
if (we)
ram[wr_addr] <= di;
assign do = ram[rd_addr];
Uses 144 LUTs with 128 of them set up as RAM16X1D (each such RAM uses 2 LUTs).
YMMV since, as is, Synplify will use TBUFs to mux 8 RAM16X1D onto each data bit so you'd need (I
think) to set syn_tristatetomux or some such.
Article: 45273THANK YOU!!! Peter The problem was indeed the reset polarity. I had been borrowing an older programmer to program the prom. It did not support the larger PROM so I had to buy a new programmer. The programmer documentation was not overly clear (it stated the reset configuration but actually meant reset_bar). I had forgotten about the polarity issue. I tried the other polarity and the FPGA now tries to boot properly. Other problems still remain but they should be relatively simple to fix (I hope). Thanks again, Theron Hicks "Peter Alfke" <peter@xilinx.com> wrote in message news:3D35EF8E.3DDD6DC3@xilinx.com... > I would look at the data output from the PROM = Din of the FPGA and check > whether there is a steady stream of data. > I assume you have the right RESET polarity ( reset_bar ) > > Peter Alfke > ================================= > Theron Hicks wrote: > > > I have a design with a spartan2e that I cannot get to release the done > > signal. > > > > the configuration is m0 and m1 =logic 0 and m2=logic 1 > > > > reset/oe connects to init_bar > > done to ce > > din and cclk to data and clk > > > > also the clk does not stop > > > > I am using the standard default configuration options. > > > > Any help? > > > > Thanks, > > Theron >Article: 45274
John Hovell <jhovell@yahoo.com> wrote in message news:9402973.0207171435.65b6a3c0@posting.google.com... > Hi -- > > I solved my own problem. Looks like I need to do a master reset > anyways -- even if there is data loaded into the RAM initially. Makes > no sense to me. I'm not sure how you would ever access those initial > values if you have to reset before the thing will work. Thank > goodness I don't need initial values. The reset on the RAM component clears the output latch of the synchronous memory, not the memory contents. I think your first read operation will also clear the Xs. It does seem like a bug that they come up Xs in the first place. JCC
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z