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
Hello,
I try to do Partial Reconfiguration for virtexE using xapp290, with
XST,
But I have some problems with bus macro:
I don't really know, How and When, I need to integrate the Bus macro
in the design flow with XST.
I think, I well declare and instanciate the bus macro in my my
top.vhd:
-My busmacro declaration in top.vhd is:
component bm_4b
port(
LI : in std_logic_vector (3 downto 0);
LT : in std_logic_vector (3 downto 0);
RI : in std_logic_vector (3 downto 0);
RT : in std_logic_vector (3 downto 0);
O : out std_logic_vector (3 downto 0)
);
end component;
-My bus macro intanciation in top.vhd is for example:
BM_UPPER_HALFWORD_I : bm_4b port map (
LI(2)=>INT_MAP_I_L(6),
LI(1)=>INT_MAP_I_L(5),
LI(0)=>INT_MAP_I_L(4),
LI(3)=>INT_MAP_I_L(7),
----------------
LT(3) => GND_L, -- "enable" the left side
LT(2) => GND_L,
LT(1) => GND_L,
LT(0) => GND_L,
----------------
RI(3) => GND_R,
RI(2) => GND_R,
RI(1) => GND_R,
RI(0) => GND_R,
---------------
RT(3) => VCC_R,
RT(2) => VCC_R,
RT(1) => VCC_R,
RT(0) => VCC_R,
---------------
O=>INT_MAP_I_R(7 downto 4)
);
In the top.ucf I put manually the following declarations:
INST "bm_upper_halfword_i" LOC = TBUF_R16C9.*;
-Q:Is it correct?
So after synthetise top.vhd with XST the top .vdh, I copy the top.ngc
and top.ucf in a directory implementation\top
If I also put the bm_4b.nmc in this directory and I try to start with
the first command of the modular flow i.e. : ngdbuild -modular initial
top.ngd
I have this error msg:
ERROR:NgdBuild:76 - File "..\Implementation\Top/bm_4b.nmc" cannot be
merged into block "bm_upper_halfword_i" (TYPE="bm_4b")because one or
more pins on the block, including pin "LI<3>", were not found in the
file. Please make sure that all pins on the instantiated component
match pins in the lower-level design block (irrespective of case).If
there are bussed pins on this block, make sure that the upper-level
and lower-level netlists use the same bus-naming convention.
If I don't put the bm_4b.nmc file in the directory I have no error but
in this case in which phase of the modular flow this file is use for
the merging and what is the command?
I have some others questions, I hope that help you to answer me if you
are always reading this long msg!:
Do I need to change somethings else in the bm_4b.nmc file that the
conponent package reference?
Do I need to consider bus macro as a module, and run the modular
design flow exactly in the way as with my own modules
Thank you for your help,
JP
Article: 55051SENG digitale Systeme GmbH is pleased to announce the availability of the self bootable FPGA based system "digital logic kernel - dlk51" with integrated PC interface What for: - development platform - rapid prototyping - education Features: - PC parallel port interface for administration and data transfer (500 Kbytes/sec) - self bootable FPGA design - no additional programming tools or download cables, no pre-programmed parts needed - xc2s50 or xc2s100 Spartan2 FPGA - xc9572xl CPLD, programmable via FPGA DLC5 emulation - 8032 CPU - RS-232 and i2C serial ports, 16 Kbit i2c EEprom - 512 Kbytes parallel flash memory for 4 CPU programs (4x64 Kbytes) and 2 FPGA config files - on board power supply, external AC or DC - all 3V3 design - size 80x100mm, signals available at 100mil, 96-pin connector DIN41612 - Xilinx DLC5 download cable emulation via FPGA - windows administration program, including sources, driver and DLL - demo programs, CPU and FPGA sources and unlimited free 8032 C compiler included - all sources available For further information see: http://www.seng.deArticle: 55052
Uwe, Doesn't have DDR built in either. Oh well, I guess their market doesn't need 'at speed' SRAM interfaces. Austin Uwe Bonnes wrote: > KB <khimbittle@cliftonremovesystems.com> wrote: > : On Mon, 14 Apr 2003 16:59:06 -0400, Theron Hicks > : <hicksthe@egr.msu.edu> wrote: > > :>Has anyone noticed that this part is available with LEGS? It appears > :>that someone at Xilinx was listening to the request for non-BGA parts. > :> > > : Actually I was a little disappointed in this area. Only the XC3S50 / > : 200 / 400 is available in the 208 pin pqfp .. the 2e took this package > : up the 300 part so some improvement yes .. but the Cyclone EP1C12 is > : available in a 240 pin pqfp ... 30+ more I/O pins, and the cyclone has > : 12K registers , a bunch more than the new 400 part. my 2'c KB > > But I don't see on-chip termination for the Cyclone part. Or did I miss > something? > > Bye > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 55053
If the example you showed didn't include the synch or asynch load that would be implemented in the flops' SR inputs, there could be reason for the mispacking. If the registers are simple FD primitives when they get to the Xilinx tool, there should be no reason to split the adder apart. The RLOCs can be specified for the registers that the adder feeds: out1 in your example. The carry chain is the more difficult part since your synthesis tool probably has its own creative way of naming the adder chain. If you determine the name of the least significant bit(s) of the adder, it's often enough just to specify the rloc of the start of the chain and the rest follow. So - RLOC your registers and the start of your chain. If there was a serious reason why the Xilinx tools couldn't cooperate with the pleasant packing because of problems with shared resets or shared clock enables or some other low level conflict, the tools will report that they can't pack the items together and tell you why. (or at least that's the behavior with LOCs - probably also with RLOCs) Good luck. "Jake Janovetz" <jakespambox@yahoo.com> wrote in message news:d6ad3144.0304241738.3690c5e5@posting.google.com... > Hello- > > I have a large adder (48-bits to 64-bits) that I am implementing in a > Spartan IIE using Verilog synthesis. I assumed that the adder LUTs, > carry logic, and resulting flip-flops would be placed in a column of > CLBs but alas, they are not. Instead, the carry logic is nice, but > the other stuff is sort of scattered about. > > So, I tried to pull out the floorplanner and throw things around the > way I think they should be, but the tool won't let me. My questions > are: > - Why doesn't the placer do things correctly? This seems like a > no-brainer placement problem to me. The carry chain alone provides a > pretty hefty constraint. > - Can the adders be forced to be implemented as an RPM without doing > the whole coregen thing or building my own adder and rloc'ing it? > - Is there some limitation that I'm missing that won't allow the LUTs > to be stacked reasonably and in the same slice? > > Now, for the purposes of this email, I've simplified somethings, but I > think justifiably so. Namely, the adder is really: > always @(posedge clk) begin > out1 <= val + (sel ? out1 : out0); > end > > Where 'sel' is a mux select and val is a register. The mux/adder > should fit nicely in the LUT (and does). > > Cheers, > JakeArticle: 55054
Dang! Typo on line 739 of the case statement. Distilling a problem to its essence will often produce the best results. Though when we get too creative, ample comments become a requirement. "nospam" <nospam@nospam.invalid> wrote in message news:kgeiav8p95jerg36q6eb9o438ncq50ojgm@4ax.com... > RISC_taker@alpenjodel.de (RISC taker) wrote: > > >Hey, I need to calculate (n mod 3) in a Virtex-II design. n is a > >10-bit unsigned number and 3 is a constant. This has to be done in the > >same cycle (combinatorial!). Now what's a good way to implement that? > > > >I thought of a lookup table (distributed RAM) but this takes quite a > >lot of space. Any better ideas? (Ray, the arithmetic guru? :-) > > A good way of implementing it? > > Write a 1024 case switch assigning the required output. > > If the solution is a simple combinatorial expression the tool will create > it - no arithmetic guru required. > >Article: 55055
I'm sorry to have to tell you this, but schematic entry for FPGA design is dead. VHDL is being taught at the undergrad level because the schools realize this. I would suggest that you learn VHDL or Verilog. These are two very powerful languages that make hardware design a lot easier and are more powerful then schematic entry will ever be. VHDL and Verilog allow for the code to be portable accross operating platforms and simulator, synthesis, and implementation software. I along with many other hardware engineers can already see the day when your boss doesn't hand you a Word or PDF document for the specifications of a design, but instead will hand you a VHDL or Verilog testbench file. The testbench file will be able to test the design for not only logic accuracy, but also timing specifications since VHDL and Verilog files can be generated post implementation which contain both gate and path delays associated with the netlist. I'm sorry that you are having trouble with the schematic software, but I imagine there will be a day(soon) where it is removed from the software completely and is only an option. Good luck.... "eric - Mtl" <notervme@sympatico.ca> wrote in message news:RvBoa.515$Zj2.58507@news20.bellglobal.com... > > > rickman wrote: > > > > > > I was a die hard schematic user too. I felt that I had better control > > over my design with schematic. But then I worked with VHDL for awhile > > and I realized the power. It can be a bit of a PITA to really optimize > > the hardware, but using schematic does not really assure you of getting > > what you put on the page. The tools optimize things sometimes since > > they know more than you do :) > > > > But the transition was really confirmed for me when I started writing > > test benches to verify my design. I can generate a model of a bus or an > > ADC or any other logic external to my design that I need to test it. > > With the waveform editor I had to *plan* my simulation very > > laboriously. If anything changed, I would often have to redo large > > parts. With an HDL test bench the test bench interacts with your design > > the same way the real board does. > > > > > > > >>If I had to rank quality and code stability for ECS, it would > >>be very close to the bottom. > > > > > > ...snip... > > > > > >>I don't know how many Xilinx users actually use ECS and if peoples from > >>the ECS development team ever read those NG posts, but I'm pretty sure > >>other users too experience these inconveniences on a daily basis and would > >>appreciate to see them addressed as much as I do. > > > > > > I am sure your many bug reports are valid and hopefully someone will > > address them. I did not read the details. Did you report many of > > these? If they are not reported, they can't be fixed. I know this > > takes time, but at this point if you are vested in the tool, it will be > > up to you to report the bugs. > > > > I don't know how many ECS users there still are, but I can tell they > > must be real die hards. I realized that HDL was the way to go when Ray > > Andraka switched. He designs hierarchical, blocked out, highly > > floorplanned designs. In the past he had built up a large library of > > schematic elements that allowed him to build large DSP designs very > > quickly complete with schematic specified floorplanning. I know from > > experience that this took a lot of effort to implement. But once he was > > forced by a contract to work with an HDL, he realized the labor savings > > from working with code and once he started converting his symbol library > > to a code library, I don't think he ever looked back. Perhaps I should > > not put words in his mouth, but this is what I have gotten from reading > > his posts. > > > > > > > >>Also, since most new users start with schematics, pissing them off from > >>day one with such a buggy software is probably not a wise thing to do. > > > > > > That may have been true in times past, but I think newbies now start > > with an HDL. When I went to school, Fortran was still the only required > > language in EE. Now I don't think you can earn a BSEE without knowing > > some HDL. I have met HDL designers who work in HDL without even drawing > > a block diagram of what they want. This is very alien to me but it > > seems to be the norm now. I think the time of schematic has passed. > > > > > Hi, > > thanks for your answer, I hear your arguments to switch from schematic > to HDL. As you acknowledge, transition is long and painful until you > reach the point where you can achieve optimized designs approaching > the gate count you get using schematics. after going through this you > are certainly right that the productivity is better. > > But why is it so ? because of the HDL's intrinsic qualities in part, > but certainly a lot too because schematic entry is so much crippled > by the tool ... > > Right now, I'm starting to use small VHDL blocks (Such as XAPP223 UART) > I get what it does, but investing the time that would be needed to > start a product from scratch using HDL is another story. > > As you mention, I see how HDLs are far better to generate test benches, > but when it comes to documentation, and having other peoples understand > what you did, a picture is still worth a thousand words ... > > I think it's at least a bit premature to announce the death of schematics, > mostly when text based traditional programming language are going the other > way around toward schematic representation to cope with complexity. > A well known product in this area is Rational Rose (now owned by IBM) > http://www.rational.com/products/rose/index.jsp > > ****** > > However, my message was not about schematic entry. It was about ECS > being a very sub standard, badly designed & buggy software. Xilinx > knows it and does not fix it. > > Such a widening quality gap between the hardware and the dev. soft > should be a bigger concern for the folks at Xilinx ... > > Filling a report ? why bother ? Countless others did it before me without > any result. The infamous "WinApp c:570" error (software crash when moving > stuff around or deleting nets) was supposed to be solved in 3.x, then 4.0 > then 4.1 and is still here in 4.2 ... > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID= 1&getPagePath=13501 > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID= 1&getPagePath=14774 > > Needless to say, the "fix" does not fix anything ... > > Maybe I should try 5.2, but it's so buggy and my confidence level is > so low that I'm not willing to do it in the middle of the design, > since I don't want to end up locked by a "to be fixed in next release" > bug and with files I can't edit anymore with the 4.2 I'm using now. > > That's the kind of trouble I could accept for a non critical piece of > shareware, but certainly not from Xilinx. > > ****** > > Forcing the switch to HDL by making the schematic tool barely usable > is a bit like poisoning water supply to increase bottled water sales. > > It might finally work (including for me), but I hate it, and I hate being > forced to waste months becoming proficient in another way to do very same > things I'm already doing now using a tried, tested and true method that's > now barely usable because the tool is screwed ! > > Believe me, using such a buggy tool on a daily basis is an incredibly > frustrating experience ! > > Eric. >Article: 55056
I've finally gotten around to updating the Xilinx on Linux HOWTO page. It's available at, http://www.polybus.com/xilinx_on_linux.htmlArticle: 55057
Hi, you can download for free a PCI Core suitable for Cyclone FPGA. The core has a built in time-bomb, for commerciale use you must purchase the core. Bye Powermos -- ---------------------------------------------------- Ama il tuo mestiere con passione E' il significato della tua vita Auguste Rodin (1840-1917) "Paul Leventis" <paul.leventis@utoronto.ca> ha scritto nel messaggio news:SY8qa.141485$BQi.97105@news04.bloor.is.net.cable.rogers.com... > Hi Mike, > > One product Altera offers is the PCI32 Nios Add-on Dev Kit. This is a board > that you hook-up to any Nios dev kit (including the Cyclone version), and > you can plug it into a PCI32 slot. It provides a PCI interface to your Nios > dev board, an API, etc. I don't know anything about it besides what's on > our web site. > > You can read about it here: > > http://www.altera.com/products/devkits/altera/kit-dev_nios_pci32.html > > - Paul > > "mike" <mxv@yahoo.com> wrote in message > news:8ea508fe.0304242036.224f0c6e@posting.google.com... > > I've searched the web with no luck for a PCI development board with > > using an Altera Cyclone part. Probably because it's a new part, but if > > anyone knows where I can find one, please post a link. It must be > > Cylone, and it can be a PCI board or PMC module. > > > > Thanks in advance. > >Article: 55058
Hy, I'm a newby into this ng, I'm interesting to built a simple FIR filter into Spartan/XC5202 FPGA, a simple filter into BF range, only purpouse is to understand of digital filter. Can someone help me with this task? The filter can be a pass-band into the audio range, from 0 to 20 kHz. Thanks in advance for your help Powermos -- ---------------------------------------------------- Ama il tuo mestiere con passione E' il significato della tua vita Auguste Rodin (1840-1917) "Ray Andraka" <ray@andraka.com> ha scritto nel messaggio news:3EA4CE10.2C3EA066@andraka.com... > I posted a reply for this filter in comp.dsp suggesting a DA approach. > > Arthur Herbert wrote: > > > rAinStorms wrote: > > > You could pre-add to improve processing bandwidth: (Zx + Zn-x).bx > > > This means 128 Complex multiplies and adds every 30MHz ... about 4Gigs > > > Performance... > > > > The FIR to be designed has no symetric coefficients (if this is what you > > suggest) > > > > > > > > I would say that this one is challenging :-) > > > > > > Not sure if you will pull it off even with a big one. > > > > > > I would propose you use a big Stratix - with its inbuilt MACs you might have > > > a show. > > > > Might be. Do you think that muxing could help spare some CELLs, i mean > > having a set of 32 Multiplier blocs each processing 8 times 30MHz would > > 'only' use 2 big stratix... innit ? > > > > > Dynamic update ... Are you saying you have to be able to update coefficients > > > while filter running? Dont forget the associated distortion if this takes > > > longer than a sample to do. > > > > Yes. Do you have some references about that sort of distorsion ? > > > > > All memories can be configured as dual port ... if you dont need update in > > > one sample then its easy. > > > If you do ... then there are lots of memory ESBs on the Stratix so you can > > > mux them - providing a way to update all coefficients at the same time. This > > > would slow the whole thing down due to muxes. > > > > > Thanks a lot for your advices, > > Arthur ;) > > > > > > "Arthur Herbert" <herbert.arthur@caramail.com> wrote in message > > > news:3EA3B77A.1020305@caramail.com... > > > > > >>Hi - > > >> > > >>I would like to implement a 256 tap complex FIR filter. > > >>It should run at 30MHz and latency should be lower than 200ns... > > >>Moreover, the coefficients should be updatable 'live', ie, without > > >>interrupting the filtering process... > > >>Seems to be quite a hard task ! > > >>Does anyone have an idea of FPGA implementation ? > > >>What kind of circuit should be used ? > > >>How many CLB/LE would it take ? > > >>Thanks in advance > > >> > > >>Arthur > > >> > > > > > > > > > > > -- > --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: 55059
Can you give me major information about this? I'm currently working with Spartan device, throught the compiler option I can configure the device in fast or slow mode. Current consuption must be less into slow mode, it's right? Best regards Powermos -- ---------------------------------------------------- Ama il tuo mestiere con passione E' il significato della tua vita Auguste Rodin (1840-1917) "Austin Lesea" <Austin.Lesea@xilinx.com> ha scritto nel messaggio news:3EA4165D.7D31410B@xilinx.com... > Lost, > > All FPGAs don't have this problem. For example, Virtex II, Virtex II Pro, > and Spartan III don't have this problem. > > "This problem" was something that had to be fixed by IC design, and > avoided. So it is not a natural result of an SRAM based FPGA. > > Austin > > LostSignal wrote: > > > > Does Altera officially recognize the Power On Surge problem ? > > > I didn't find any references to this problem in Altera's datasheets or > > > App. notes. Their datasheets don't specify start up current as well. > > > One of our designs sometimes has strange power-up problems at the low > > > temperature. We never attributed this problems to the FPGA. Actually I > > > didn't hear about this problem before (thank you, Martin). Now I'm > > > starting to suspect that the problem is related to FPGA. The design is > > > based on ACEX 1K100 device. Where can I find Power On Current profile > > > for this device ? > > > > Apparently ALL SRAM based FPGAs experience this problem to some > > degree. At the startup the configuration SRAM is in unknown state and > > that causes large current surge that must be satisfied in order for > > FPGA to configure properly. AFAIK the differences between Xilinx and > > Altera in this regard are: > > 1. Xilinx publicly acknowleged this problem some time ago has several > > articles on it. I have not seen much from Altera (correct me if I am > > wrong). > > 2. The rumor is Altera has a somewhat smaller surge and people have > > less trouble with it. Dunno how true it is though. I've heard from an > > Altera guy that a really large Altera part can draw 2.5 A. The maximum > > current specified for Xilinx is 2 A at low temperature. Go figure.. > > > > Lost Signal >Article: 55060
Hi, I'm new into this ng. I've interest into digital filter, my present work is with FPGA like Spartan and XC5202 family. Can you give me an example of digital filter implementation? I've no material about this, only knowledge is about my control theory course and is about digitizing the analog filter throught the Z-transform technique. I'm very gratefully if you can help me. Thanks in advance and best regards Fabio Filippa -- ---------------------------------------------------- Ama il tuo mestiere con passione E' il significato della tua vita Auguste Rodin (1840-1917) "Philippe Molson" <philippe_molson@yahoo.com> ha scritto nel messaggio news:e1558d23.0304171903.5a14ad71@posting.google.com... > Hi, > > Some band-pass IIR filters require large precision. The Fixed-point > analysis depends heavely on the IIR characteristics. > > Altera has developed several tools to help you to design fixed-point > IIR filters. > > You can probably start by downloading the Altera IIR-Compiler > http://www.altera.com/products/ip/dsp/filtering/m-alt-iircompiler.html > > This is an IP. With the evaluation version, you start from the > floating-point IIR coefficients and use the built-in floating to > fixed-point conversion analysis tools. This help you to determine > which bit can be truncated in both feedback and feedforward data-path. > The IIR-compiler is interactif and displays dynamically the filter > response in the zero-pole or frequency or time domain, based on > parameters such as bit-width selection/truncation (among others) > > In addition, in this tool you can evaluate various IIR structures, > such as direct form II, biquad cascaded or biquad parallel. You > probably will find out that the fixed-point maths vary from one > structure to another. You can also trade-off FPGA multiplier/adder > style (parallel distributed arithmetic, MAC based). > > If you are familiar with Matlab Simulink, another option consists of > using the DSP Builder, which is a Simulink plug-in and can be > downloaded from : > > http://www.altera.com/products/software/system/products/dsp/dsp-builder.html > > From the Simulink cockpit , you can use the IIR compiler, or build the > IIR structure with the DSP Builder primitives (Multiply, Add, LUT ...) > optimized for Cyclone or Stratix. The DSP Builder-Simulink flow gives > you enhanced sink and source block for system analysis, and this could > be very usefull in this case when you need to analyze complex aspects > of fixed-point IIR design such as stability. > > Building the filter with DSP Builder primitive may take longer than > using the IIR-Compiler, however it may allow you to explore FPGA > architectures implementation which are not yet present in the > IIR-Compiler such as multi-bit serial. > > I hope that this will help you to build efficient IIR filters for > Cyclone device. > > > Philippe Molson > Altera Corporation > > > "gallenm" <gallenm@ic24.net> wrote in message news:<v9tmpdn101mb60@corp.supernews.com>... > > Hi, > > Just adding a plug for ONEoverT digital filter designer. It will > > automatically produce > > synthesizable VHDL for IIRs and FIRs. Very cheap, the demo can be downloaded > > from > > the website > > www.tyder.com > > > > If you download the case study, it will show you the implemention of an IIR > > onto a Spartan > > FPGA. > > > > Yours > > Alan Mc Kitterick > > www.tyder.com > > > > "Pramod" <pramod@procsys.com> wrote in message > > news:a7c0720d.0304152101.581c85be@posting.google.com... > > > Hi All, > > > I am new to this group and also to the field of FPGA based design. > > > I have some doubts and issues which I feel will be easy for you guys > > > to answer. > > > 1. For a 4 pole IIR Filter in FPGA (targeted device EP1C6), I have a > > > spec of 24 bit wide data input and > > > 32 bit wide coeff (dynamic) inputs. So, the multiplied results should > > > ideally have > > > 56 bits width. Are these widths practically relevant for a 4 pole > > > filter > > > or can we get an affordable precision with rounding to lower sizes? > > > If so, can anyone suggest a standard procedure for > > > rounding the results with lowest error and without causing the output > > > to become unstable? > > > 2. Another thing I would like to get some advice is, if I go with the > > > 24 X 36 busses, > > > since I have to implement a number of such filters in a single device, > > > the bit-parallel implementation will take up huge resources. > > > The digit serial approach using (either small multiplier or LUT > > > method) > > > also will end up in huge resources due to big number of partial > > > products and sums involved. > > > If anyone can suggest any alternate method it will be of great help to > > > me. > > > 3. On another front, in a timing simulation scenario I am using > > > Quartus II .vo output and ModelSIM PE. My code has > > > a ROM (ALTSYNCRAM megafunction used to generate this). I found some > > > differences in the > > > readout data during timing simulation between using .MIF format file > > > and .HEX format file for initializing ROM > > > eventhough the QII displayed same contents in the memory editor. > > > Has anyone ever faced any such issues? > > > Hoping to get some valuable leads on these.. > > > Thanks in advance, > > > Pramod >Article: 55061
Michael Condon wrote: > . . . I along with many other hardware > engineers can already see the day when your boss doesn't hand you a Word or > PDF document for the specifications of a design, but instead will hand you a > VHDL or Verilog testbench file. Wow. The future is bright. In 2003, I'm lucky to get 3 bullet items on a powerpoint slide :) -- Mike TreselerArticle: 55062
>Dang! Typo on line 739 of the case statement. > >Distilling a problem to its essence will often produce the best results. >Though when we get too creative, ample comments become a requirement. Write a program to write the body of the code for the case statement. It's just a big table - the same bits you would need if you did the RAM approach. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 55063
Austin - are you saying the Cylcone parts don't have DDR? So the dedicated DQS elements are there for... what purpose? The Cyclone parts claim support for PC2100 speed DDR (133MHz clock). The IOBs may only have 3 registers as opposed to the 6 in the Spartan3, but DDR can work. The Spartan3 can deliver much higher speed and higher performance because of the tight timing allowed by the DDR IOB configuration but care still has to be taken with a "global" DQS timing methodology. My personal opinion: Spartan3 is much better than Cyclone for DDR but the DQS implementation is cleaner on the Cyclones allowing for layout skew of the data groups. "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3EA95029.8C917454@xilinx.com... > Uwe, > > Doesn't have DDR built in either. Oh well, I guess their market doesn't > need 'at speed' SRAM interfaces. > > Austin > > Uwe Bonnes wrote: > > > KB <khimbittle@cliftonremovesystems.com> wrote: > > : On Mon, 14 Apr 2003 16:59:06 -0400, Theron Hicks > > : <hicksthe@egr.msu.edu> wrote: > > > > :>Has anyone noticed that this part is available with LEGS? It appears > > :>that someone at Xilinx was listening to the request for non-BGA parts. > > :> > > > > : Actually I was a little disappointed in this area. Only the XC3S50 / > > : 200 / 400 is available in the 208 pin pqfp .. the 2e took this package > > : up the 300 part so some improvement yes .. but the Cyclone EP1C12 is > > : available in a 240 pin pqfp ... 30+ more I/O pins, and the cyclone has > > : 12K registers , a bunch more than the new 400 part. my 2'c KB > > > > But I don't see on-chip termination for the Cyclone part. Or did I miss > > something? > > > > Bye > > -- > > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >Article: 55064
Hi there , I want to imlpement LDPC codec using VHDL language , any help on materials available will be highly appreciated. Thanks you very much in advance. Regards, KhanArticle: 55065
Berend Ozceri (snip _news_ from address to reply) wrote: > I just came across Northwest Logic's (http://www.nwlogic.com) PCI/PCI-X > core offerings (for Altera and Xilinx) and was wondering if there were > any folks out there who have used them (or other cores from Northwest > Logic) and would like to share their experiences. My experience was good. Not a PCI core however. The core worked. The documentation was very good. The support and testbench was OK. The source was was a little messy with lots of commented code blocks and wrappers on wrappers, but having the source proved essential for system integration. -- Mike TreselerArticle: 55066
Hi Gurus, I am doing project on developing LDPC coder and decoder using Xilinx FPGA. Any help as far as material links and VHDL code will be highly appreciated. Thanking you in advance, KhanArticle: 55067
> > > I am wondering if you know any available FPGA devices which are dynamically > > > reconfigurable. I am doing a project in the area of evolvable hardware and I > > > am looking to buy a board with dynamic reconfigurable FPGAs. > > You can get kind of a dynamic reconfigurability out of SpartanII device. I've never tried this, but I think it should work. The SRL16 feature can be used to reload LUT ram contents, acting effectively as a second write port to the LUT. Since the LUT ram can be reloaded it can change the logic function of the LUT. By wiring up LUT's appropriately it should be possible to get some facsimile of a dynamically reconfigurable part. RobArticle: 55068
Hallo, the Spartan-3 datasheet talks about the XCF configuration Flash PROM parts. I found no further information. Any pointers? Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 55069
Austin Lesea wrote: > > Uwe, > > Doesn't have DDR built in either. Oh well, I guess their market doesn't > need 'at speed' SRAM interfaces. I believe that I have read posts by Xilinx people about how they don't like to comment on competitor's products here because they don't want it to sound like they are ragging on them... Do I need to say anything more? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 55070
Thanks for the info, Ray... I took a short stint into the full-custom ASIC arena and I'm back on FPGAs for a bit. I've taken a peek at things under the FPGA editor and all looks good. However, I did notice one thing in the floorplanner: I had the P&R tools do their thing, then copied the placement to the constraint so I could edit it. I moved a FF out of a packed slice (FF & carry chain together as they should be) and was not able to move it back! So, somehow what's good for the P&R tools is apparently not good for Jake. The carry chain is in tact and I'm not adding constants. Both values come from regs. You know -- Verilog now has a generate in the specification, but I don't think it has made its way into the XST tools yet. Anyone here on the FPGA list fiddled with Lava yet? Jake Ray Andraka <ray@andraka.com> wrote in message news:<3EA8AE63.A3824049@andraka.com>... > Jake, > > Been a while since I've heard from you... Anyway, you've discovered one > of the warts on the tools. There are several things that can make it > impossible to pack the carry chain components properly. If you have > access to a mapped HDL viewer, I would reference that to see what the > synthesis did to your adder. Some possibilities: > > 1) it might have put logic between the carry chain and the register. > Typically this is a mux after the add or a sync reset that didn't get > sucked into the flip-flop (usually because of a global reset already > occupying the pin). > > 2) a clock enable or reset net is split up so that registers that should > have been packed can't be > > 3) The carry chain got messed up. This can happen if you are adding a > constant. I've seen synthesis 'optimize' a carry chain where one or more > bits are constants in such a way that the carry chain can no longer be > placed. What typically happens is you get two sub-chains. If the bottom > of the upper chain is on an odd bit, the placer will shift the chain down > by half a slice. Put a syn keep on the constant input signal to avoid > this. > > 4) The LUT logic can get strewn hither and yonder by optimization that > breaks the LUT down in funny ways. > > 5) Finally, the placer just doesn't do a very good job with the logic > associated with carry chains for some reason. You can sometimes improve > the results by adjusting the timing constraints, but only if the packer > has already properly paired the pieces. > > For stuff that is speed or density critical, I find it is easier just to > do the RLOCing using a generate....oh yeah, you are using Verilog so you > don't have a generate. That makes the RLOCs a lot more awkward. > > Jake Janovetz wrote: > > > Hello- > > > > I have a large adder (48-bits to 64-bits) that I am implementing in a > > Spartan IIE using Verilog synthesis. I assumed that the adder LUTs, > > carry logic, and resulting flip-flops would be placed in a column of > > CLBs but alas, they are not. Instead, the carry logic is nice, but > > the other stuff is sort of scattered about. > > > > So, I tried to pull out the floorplanner and throw things around the > > way I think they should be, but the tool won't let me. My questions > > are: > > - Why doesn't the placer do things correctly? This seems like a > > no-brainer placement problem to me. The carry chain alone provides a > > pretty hefty constraint. > > - Can the adders be forced to be implemented as an RPM without doing > > the whole coregen thing or building my own adder and rloc'ing it? > > - Is there some limitation that I'm missing that won't allow the LUTs > > to be stacked reasonably and in the same slice? > > > > Now, for the purposes of this email, I've simplified somethings, but I > > think justifiably so. Namely, the adder is really: > > always @(posedge clk) begin > > out1 <= val + (sel ? out1 : out0); > > end > > > > Where 'sel' is a mux select and val is a register. The mux/adder > > should fit nicely in the LUT (and does). > > > > Cheers, > > Jake > > -- > --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, 1759Article: 55071
Michael Condon wrote: > I'm sorry to have to tell you this, but schematic entry for FPGA design is > dead. I'll add it to my collection of "Famous Last Words" ... VHDL is being taught at the undergrad level because the schools > realize this. They teach "Java" too. does that make "C" irrelevant ? I would suggest that you learn VHDL or Verilog. These are > two very powerful languages that make hardware design a lot easier and are > more powerful then schematic entry will ever be. Do you *really* think I don't know what HDLs are ? VHDL and Verilog allow for > the code to be portable accross operating platforms and simulator, > synthesis, and implementation software. On portability, VHDL / Verilog clearly do better, since most schematic file formats are (unfortunately) proprietary. I along with many other hardware > engineers can already see the day when your boss doesn't hand you a Word or > PDF document for the specifications of a design, but instead will hand you a > VHDL or Verilog testbench file. Well, I don't have a boss. I have customers, and my customers are for now way more comfortable with a schematic diagram of the functions they want because everyone there can figure out what it's doing. This might change, but for now, that's what they like. They would certainly take VHDL code, if I make them a nice schematic diagram that explains what it does ... The testbench file will be able to test the > design for not only logic accuracy, but also timing specifications since > VHDL and Verilog files can be generated post implementation which contain > both gate and path delays associated with the netlist. When using Xilinx tools, the schematic diagrams are converted to VHDL, so I get exactly the same kind of simulation and timing analysis as if I was coding using VHDL and I don't even need to write the HDL testbench if I don't want to, thanks to "HDL Bencher" ... Schematic entry is just an additional preprocessing layer ... I'm sorry that you > are having trouble with the schematic software, but I imagine there will be > a day(soon) where it is removed from the software completely and is only an > option. Good luck.... > Ain't that FUD ? There's life outside the Newsgroup, and it seems like Xilinx is willing not only to fix ECS, but to improve it a lot. The whole point of this thread was that tool quality severely lags behind silicon quality and capabilities, and that should be a concern for "X" & "A" as well as for all users, no matter if they code using schematics, VHDL, Verilog or whatever ... Eric.Article: 55072
Michael Condon wrote: > I'm sorry to have to tell you this, but schematic entry for FPGA design is > dead. I'll add it to my collection of "Famous Last Words" ... VHDL is being taught at the undergrad level because the schools > realize this. They teach "Java" too. does that make "C" irrelevant ? I would suggest that you learn VHDL or Verilog. These are > two very powerful languages that make hardware design a lot easier and are > more powerful then schematic entry will ever be. Do you *really* think I don't know what HDLs are ? VHDL and Verilog allow for > the code to be portable accross operating platforms and simulator, > synthesis, and implementation software. On portability, VHDL / Verilog clearly do better, since most schematic file formats are (unfortunately) proprietary. I along with many other hardware > engineers can already see the day when your boss doesn't hand you a Word or > PDF document for the specifications of a design, but instead will hand you a > VHDL or Verilog testbench file. Well, I don't have a boss. I have customers, and my customers are for now way more comfortable with a schematic diagram of the functions they want because everyone there can figure out what it's doing. This might change, but for now, that's what they like. They would certainly take VHDL code, if I make them a nice schematic diagram that explains what it does ... The testbench file will be able to test the > design for not only logic accuracy, but also timing specifications since > VHDL and Verilog files can be generated post implementation which contain > both gate and path delays associated with the netlist. When using Xilinx tools, the schematic diagrams are converted to VHDL, so I get exactly the same kind of simulation and timing analysis as if I was coding using VHDL and I don't even need to write the HDL testbench if I don't want to, thanks to "HDL Bencher" ... Schematic entry is just an additional preprocessing layer ... I'm sorry that you > are having trouble with the schematic software, but I imagine there will be > a day(soon) where it is removed from the software completely and is only an > option. Good luck.... > > Ain't that FUD ? There's life outside the Newsgroup, and it seems like Xilinx is willing not only to fix ECS, but to improve it a lot. The whole point of this thread was that tool quality severely lags behind silicon quality and capabilities, and that should be a concern for "X" & "A" as well as for all users, no matter if they code using schematics, VHDL, Verilog or whatever ... Eric.Article: 55073
John_H wrote:
> If there was a serious reason why the Xilinx tools couldn't cooperate with
> the pleasant packing because of problems with shared resets or shared clock
> enables or some other low level conflict, the tools will report that they
> can't pack the items together and tell you why. (or at least that's the
> behavior with LOCs - probably also with RLOCs)
Only if the primitives are RLOC'd. If not, the packer won't pack the elements
together and the tool goes on oblivious.
I am not sure which version of the tools Jake is using. There have been
problems in the past with RPM zippering, including occasional problems where the
carry chain is automatically RLOC'd and the other stuff is not. Question for
Jake: Is the carry chain intact? Does the floorplanner allow you to place the
LUTs associated with the carry chain (it should, as long as the LUTs aren't
doing something goofy with the DI to the MUXCY's --I've seen that happen too)?
How about the ff's.
If you can't place the ff's in the floorplanner, it is usually due to
conflicting SR's or CE's. Often that is the result of buffers getting inserted
to break up a big fan-out.
>
>
> Good luck.
>
> "Jake Janovetz" <jakespambox@yahoo.com> wrote in message
> news:d6ad3144.0304241738.3690c5e5@posting.google.com...
> > Hello-
> >
> > I have a large adder (48-bits to 64-bits) that I am implementing in a
> > Spartan IIE using Verilog synthesis. I assumed that the adder LUTs,
> > carry logic, and resulting flip-flops would be placed in a column of
> > CLBs but alas, they are not. Instead, the carry logic is nice, but
> > the other stuff is sort of scattered about.
> >
> > So, I tried to pull out the floorplanner and throw things around the
> > way I think they should be, but the tool won't let me. My questions
> > are:
> > - Why doesn't the placer do things correctly? This seems like a
> > no-brainer placement problem to me. The carry chain alone provides a
> > pretty hefty constraint.
> > - Can the adders be forced to be implemented as an RPM without doing
> > the whole coregen thing or building my own adder and rloc'ing it?
> > - Is there some limitation that I'm missing that won't allow the LUTs
> > to be stacked reasonably and in the same slice?
> >
> > Now, for the purposes of this email, I've simplified somethings, but I
> > think justifiably so. Namely, the adder is really:
> > always @(posedge clk) begin
> > out1 <= val + (sel ? out1 : out0);
> > end
> >
> > Where 'sel' is a mux select and val is a register. The mux/adder
> > should fit nicely in the LUT (and does).
> >
> > Cheers,
> > Jake
--
--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: 55074
Jake Janovetz wrote:
> Thanks for the info, Ray... I took a short stint into the full-custom
> ASIC arena and I'm back on FPGAs for a bit.
>
> I've taken a peek at things under the FPGA editor and all looks good.
> However, I did notice one thing in the floorplanner: I had the P&R
> tools do their thing, then copied the placement to the constraint so I
> could edit it. I moved a FF out of a packed slice (FF & carry chain
> together as they should be) and was not able to move it back! So,
> somehow what's good for the P&R tools is apparently not good for Jake.
Hmm, I've seen that a while back. Sounds like it might be conflicting area constraints or
problems zippering logic with an RPM (the carry chain). I'd have to look at what you have
to make a better determination.
>
>
> The carry chain is in tact and I'm not adding constants. Both values
> come from regs. You know -- Verilog now has a generate in the
> specification, but I don't think it has made its way into the XST
> tools yet.
Yeah, it is in verilog 2000. I don't think any of the synth tools support '2000 yet
though.
>
>
> Anyone here on the FPGA list fiddled with Lava yet?
>
> Jake
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3EA8AE63.A3824049@andraka.com>...
> > Jake,
> >
> > Been a while since I've heard from you... Anyway, you've discovered one
> > of the warts on the tools. There are several things that can make it
> > impossible to pack the carry chain components properly. If you have
> > access to a mapped HDL viewer, I would reference that to see what the
> > synthesis did to your adder. Some possibilities:
> >
> > 1) it might have put logic between the carry chain and the register.
> > Typically this is a mux after the add or a sync reset that didn't get
> > sucked into the flip-flop (usually because of a global reset already
> > occupying the pin).
> >
> > 2) a clock enable or reset net is split up so that registers that should
> > have been packed can't be
> >
> > 3) The carry chain got messed up. This can happen if you are adding a
> > constant. I've seen synthesis 'optimize' a carry chain where one or more
> > bits are constants in such a way that the carry chain can no longer be
> > placed. What typically happens is you get two sub-chains. If the bottom
> > of the upper chain is on an odd bit, the placer will shift the chain down
> > by half a slice. Put a syn keep on the constant input signal to avoid
> > this.
> >
> > 4) The LUT logic can get strewn hither and yonder by optimization that
> > breaks the LUT down in funny ways.
> >
> > 5) Finally, the placer just doesn't do a very good job with the logic
> > associated with carry chains for some reason. You can sometimes improve
> > the results by adjusting the timing constraints, but only if the packer
> > has already properly paired the pieces.
> >
> > For stuff that is speed or density critical, I find it is easier just to
> > do the RLOCing using a generate....oh yeah, you are using Verilog so you
> > don't have a generate. That makes the RLOCs a lot more awkward.
> >
> > Jake Janovetz wrote:
> >
> > > Hello-
> > >
> > > I have a large adder (48-bits to 64-bits) that I am implementing in a
> > > Spartan IIE using Verilog synthesis. I assumed that the adder LUTs,
> > > carry logic, and resulting flip-flops would be placed in a column of
> > > CLBs but alas, they are not. Instead, the carry logic is nice, but
> > > the other stuff is sort of scattered about.
> > >
> > > So, I tried to pull out the floorplanner and throw things around the
> > > way I think they should be, but the tool won't let me. My questions
> > > are:
> > > - Why doesn't the placer do things correctly? This seems like a
> > > no-brainer placement problem to me. The carry chain alone provides a
> > > pretty hefty constraint.
> > > - Can the adders be forced to be implemented as an RPM without doing
> > > the whole coregen thing or building my own adder and rloc'ing it?
> > > - Is there some limitation that I'm missing that won't allow the LUTs
> > > to be stacked reasonably and in the same slice?
> > >
> > > Now, for the purposes of this email, I've simplified somethings, but I
> > > think justifiably so. Namely, the adder is really:
> > > always @(posedge clk) begin
> > > out1 <= val + (sel ? out1 : out0);
> > > end
> > >
> > > Where 'sel' is a mux select and val is a register. The mux/adder
> > > should fit nicely in the LUT (and does).
> > >
> > > Cheers,
> > > Jake
> >
> > --
> > --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
--
--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
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