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
>Yesterday, the nice marketing people from Gennum informed me that, in >their unbiased opinion, their GN4124 PCI Express to Local Bus bridge >chip is the finest solution that the world has ever seen for connecting >an FPGA as a PCIe endpoint, and that anyone trying to do so any other >way is sadly misguided, and will in future years be looked back on >as a group with flat Earth believers and Chicago Cubs fans. > >The surface level stuff I've had a chance to look over on the chip is >pretty interesting. At first glance, it should have no trouble handling >my needs for about a 1 Gbps average throughput and should be pretty >straightforward. But before I get too far into the depths of the >restricted datasheets, driver code samples, provided Verilog, etc, I >figured I'd go on a quick CAF fishing trip. > >Anyone had any experiences with the GN4124? Or alternatively, with the >PEX8311 by PLX, which is the only other chip I've managed to find that >performs a similair task? The ultimate project goal is going to be a >PCIe card with an FPGA talking to a mini-ITX running Linux, and I'm >likely going to be the one doing the coding on all ends. Total project >run's only likely about 200, 250 pieces, so it's easier to spend BOM >money than it is to buy expensive IP or spend weeks and weeks of extra >coding. > >-- >Rob Gaddi, Highland Technology >Email address is currently out of order > I have just completed a design using the GN4124 and it worked exactly as promised. I had to convert a 15 year old ISA bus RF modem to PCIe bus. The data rate on the legacy modem slow and I was considering using the Gennum GN4124 paired up with a Xilinx FPGA. Then, found the IP cost for the Xilinx was 14K$. I talked with Gennum and found that they have implemented a 16 bit general purpose I/O port that you can talk to directly over the PCIe bus. All the PCIe power up enumeration is handled inside the GN4124 and you don't even need the Xilinx chip at all. I took the Xilinx chip off the board and got rid of a ton of development. I purchased Gennum's RDK and hooked it into the legacy modem and got it working easily. They also have another 6 bit port which is also directly accessible through PCI reads and writes so the total is 22 bits. The interrupt system is great. You can debug the whole interrupt chain inside the GN4124 by reading and writing a group of registers. Any pin, either high or low going edge or both, and high or low level for any pin on the the 16 bit port. The 4 legacy PCI interrupts INTA-INTD are supported. Xilinx support for a small company is very tough but Gennum support is excellent. Phone calls, email - same day usually. DrBill Dr. Bill Avery S A Engineering Reno NevadaArticle: 140326
On Mar 25, 2:11=A0am, "zhj1985" <zhanghaojun1...@hotmail.com> wrote: > Generally, the most popular DSP archetecture which focused on complex > digital signal processing is based on DSP +FPGA. FPGA is often used as a > coprocessor for a DSP because those PowerPC 440 cores aren't as fast as D= SP > and those algorithms which are developed by C language can be developped > more easily than those developed by Verilog or VHDL language. > > However, as the time goes, FPGA has developped fast in recent years. I > want to ask that whether those complex digital system which was based on > DPS+FPGA can be replaced by FPGA now. And if it is, then how can I do tha= t? > I know Xilinx has developed those software such as system generator, but = I > don't know whether it can work out. Does anybody know where I can get mor= e > information about those things(By the way, I use Xilinx products)? Thanks= . It's a moving target, and depends on your application, and data bandwidths. DSPs are falling in price, and include things you will NEVER find on a FPGA, like 12 bit 4MSPS ADCs DSPs also have the memory built in, often FLASH, and also have uA region power down modes, and commonly simple, single supply operation. So IF you can find what you need in a commercial DSP, it is always likely to be cheaper, and lower power, than the incremental cost of adding that to a FPGA.. FPGAs come into their own, when you cannot find the 'mix' you need in a DSP -jgArticle: 140327
-jg <Jim.Granville@gmail.com> wrote in news:f85bd7c4-841b-45fd-848b- 6e7db0cf36ed@a5g2000pre.googlegroups.com: > On Mar 25, 2:11 am, "zhj1985" <zhanghaojun1...@hotmail.com> wrote: >> Generally, the most popular DSP archetecture which focused on complex >> digital signal processing is based on DSP +FPGA. FPGA is often used as a >> coprocessor for a DSP because those PowerPC 440 cores aren't as fast as D > SP >> and those algorithms which are developed by C language can be developped >> more easily than those developed by Verilog or VHDL language. >> >> However, as the time goes, FPGA has developped fast in recent years. I >> want to ask that whether those complex digital system which was based on >> DPS+FPGA can be replaced by FPGA now. And if it is, then how can I do tha > t? >> I know Xilinx has developed those software such as system generator, but > I >> don't know whether it can work out. Does anybody know where I can get mor > e >> information about those things(By the way, I use Xilinx products)? Thanks > . > > It's a moving target, and depends on your application, and data > bandwidths. > DSPs are falling in price, and include things you will NEVER find on a > FPGA, > like 12 bit 4MSPS ADCs > > DSPs also have the memory built in, often FLASH, and also have uA > region > power down modes, and commonly simple, single supply operation. > > So IF you can find what you need in a commercial DSP, it is always > likely to be > cheaper, and lower power, than the incremental cost of adding that to > a FPGA.. > > FPGAs come into their own, when you cannot find the 'mix' you need in > a DSP > > -jg > I think that in most cases an FPGA & DSP are good complements. We make a dspblok module with a SHARC DSP and and a Cyclone III DSP. http://www.danvillesignal.com/dspblok/dspblok-21369+fpga-analog-devices- adsp-21369-altera-cyclone-iii-dsp-fpga-modules.html Al Clark Danville Signal Processing, Inc.Article: 140328
Jukka Marin wrote: > Dear All, > > I'm wondering whether to use 10/100 Ethernet and CAN controller chips > (two of each) in a new design or just put cores from OpenCores inside > an FPGA (which we will need in both cases). I'm (still) new to FPGA's > and have never used cores from OpenCores. Has anybody used these cores? > Are they reliable and ready for production use? > > The third alternative is to buy commercial IP blocks, but I'm afraid > they might cost more than the old-fashioned way (the production volumes > will be relatively small). > > I'd appreciate any facts and/or opinions. :) > > -jm Jukka, Whose FPGA are you using? -RichArticle: 140329
On Fri, 8 May 2009 10:01:30 -0700 (PDT), peter@xilinx.com wrote: >This is not a Xilinx or Altera circuit design problem, > nor is it a VHDL problem. It is a systems design issue. With respect, Peter, it is definitely neither a circuit design nor a system design problem. Speaking for myself (and for Rick too, I'm pretty sure) I know well enough what the capabilities and limitations of the BRAMs are, and how to work with them successfully. I already know what form of BRAM I want, and I can easily enough instantiate it. I have already chosen a set of behaviours that I know are available in both Xilinx and Altera BRAMs. But I don't want the grotesque non-portable ugliness of instantiated and/or wizard-generated BRAM components. So I seek a way of writing VHDL and Verilog code that correctly describes the memories' simulation behaviour, at the appropriate level of abstraction, and that will allow a range of synthesis tools to infer correctly the BRAM properties that I need. As has already been said by others, it is not hard to do this for BRAM configurations with only one write port. As soon as you add a second write port, things get much more vexatious and you get significantly less help from the coding guidelines in vendor documentation. There are good reasons for this, as have already been discussed; I made a promise (which I aim to keep) to find out just what can be done, and to write it up in a convenient vendor-neutral form. Systems design it ain't; it's all about finding a valid HDL coding style that reliably gets a desired result out of a range of different vendors' tools. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 140330
On May 9, 5:02=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Fri, 8 May 2009 10:01:30 -0700 (PDT), pe...@xilinx.com wrote: > >This is not a Xilinx or Altera circuit design problem, > > nor is it a VHDL problem. It is a systems design issue. > > With respect, Peter, it is definitely neither a circuit > design nor a system design problem. =A0Speaking for myself > (and for Rick too, I'm pretty sure) I know well enough > what the capabilities and limitations of the BRAMs are, > and how to work with them successfully. =A0I already > know what form of BRAM I want, and I can easily enough > instantiate it. =A0I have already chosen a set of > behaviours that I know are available in both Xilinx > and Altera BRAMs. > > But I don't want the grotesque non-portable ugliness > of instantiated and/or wizard-generated BRAM components. > > So I seek a way of writing VHDL and Verilog code that > correctly describes the memories' simulation behaviour, > at the appropriate level of abstraction, and that will > allow a range of synthesis tools to infer correctly the > BRAM properties that I need. =A0As has already been said by > others, it is not hard to do this for BRAM configurations > with only one write port. =A0As soon as you add a second > write port, things get much more vexatious and you > get significantly less help from the coding guidelines > in vendor documentation. =A0There are good reasons for > this, as have already been discussed; I made a promise > (which I aim to keep) to find out just what can be > done, and to write it up in a convenient vendor-neutral > form. =A0Systems design it ain't; it's all about finding > a valid HDL coding style that reliably gets a desired > result out of a range of different vendors' tools. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Why did I call it a systems problem? The BRAM behaves like a synchronous two-port RAM should, common clock or uncorrelated clocks, as long as you do not perform "simultaneous" write and read operations on the same location. Two writes with conflicting data will leave the content undefined, while a write and a read can result in an undefined output. Two reads are no problem. Protecting against these system issues is quite complicated, and would sacrifice performance. What does the user community expect from us (Xilinx)? Peter AlfkeArticle: 140331
hi all,
the clock frequency of my fpga board is 125Mhz and i need to
process data from a sensor which is at 1khz to generate an 8bit data.
for that i tried to sample the data 256 times ie i tried to generate a
clock with frequency 256khz=0.256Mhz. i tried to generate the new
clock by using a counter with followin calculation
125/(2^n)=0.256
n=8.93
so i went for a 9 bit counter taking n=9.
but due to the roundoff there is some error in the design.could
somebody suggest be a better way for sampling the data.
any suggestions would be highly appreciated.
also what i would like to know is , is using the counter only way for
achieving lower frequency clocks or are ther other alternatives with
more accurecy?
any suggestions would be highly aprreciated.
thank you
Article: 140332
Peter Alfke wrote:
> Protecting against these system issues is quite complicated, and would
> sacrifice performance.
> What does the user community expect from us (Xilinx)?
What if we wrote you a vhdl and verilog model
that captures your English description above
and a testbench to demonstrate that modelsim agrees.
Then you would give the models to the right person
and see to it that ise will synthesize
a netlist that passes the same testbench.
-- Mike Treseler
Article: 140333Peter Alfke wrote: > Why did I call it a systems problem? > The BRAM behaves like a synchronous two-port RAM should, common clock > or uncorrelated clocks, as long as you do not perform "simultaneous" > write and read operations on the same location. > Two writes with conflicting data will leave the content undefined, > while a write and a read can result in an undefined output. Two reads > are no problem. > Protecting against these system issues is quite complicated, and would > sacrifice performance. > What does the user community expect from us (Xilinx)? I didn't need such a feature so far, but with Altera Quartus you can specify for dual port RAMs, if you want to read the old content when simultaneous writing at the same location, or you can speficy "I don't care" (which I assume is faster). Maybe this features makes sense for some projects. But I don't think that it makes sense to specify the behaviour, if a BRAM has two write ports and from both ports are written to the same address simultaneously. And if it makes sense, it should be easy to catch this rare case in user logic, e.g. a simple priority algorithm with static logic. Implementing this for the write/read-case in user logic would be more complicated and maybe slower than what is possible with low-level support. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 140334
<prashant.gyawali@gmail.com> wrote in message
news:8cee21a7-2632-4552-b023-e4f4bce56ba2@e23g2000vbe.googlegroups.com...
> hi all,
> the clock frequency of my fpga board is 125Mhz and i need to
> process data from a sensor which is at 1khz to generate an 8bit data.
> for that i tried to sample the data 256 times ie i tried to generate a
> clock with frequency 256khz=0.256Mhz. i tried to generate the new
> clock by using a counter with followin calculation
> 125/(2^n)=0.256
> n=8.93
> so i went for a 9 bit counter taking n=9.
> but due to the roundoff there is some error in the design.could
> somebody suggest be a better way for sampling the data.
> any suggestions would be highly appreciated.
>
Counters do not need need to count through their entire 2^n cycle. You know
the FPGA clock period, you know the sensor clock period, the ratio of those
two times tells you how many FPGA clocks there are per sensor period...so
you create a counter that counts in that range, you don't round it up to the
next 2^n count. Below is some VHDL code to mull over.
From your description, I'm not sure what exactly you're trying to do with
your sensor data. It sounds like you can sample it at a 1KHz rate, but
don't really get what in the world you're trying to do with the 256 KHz that
you mentioned. The code below shows you how to create a timer for an
arbitrary constant time period which seems like the root problem you're
trying to understand. Once you have the basic counter, you can use that to
do all kinds of things at any point in the counter's sequence. As an
example, I created a 'Sensor_Clock' that would be a free running 1 KHz, 50%
duty cycle signal. You can also decode whatever other counter values you'd
like if you need to do something at different points (i.e. there is nothing
special about the constant 'HALF_PERIOD' used in the code below, it's just a
number). If you want to define 256 points within that cycle where you do
something you simply define 256 constant values that you will compare with
'Sensor_Counter' (which I'm guessing is where you came up with the 256 KHz,
but not sure what the significance of those 256 points are). Those 256
points don't necessarily have to be evenly spaced.
The only error sources (i.e. deviations from sampling at exactly 1 KHz) that
are caused by the code below itself are:
- The resolution of the FPGA clock. In this particular case, the 8ns
resolution of the FPGA clock will not be an issue, but if you're trying to
time something that is not an integer multiple of 8ns clocks it might
matter.
- In general, you can't count on the ratio of your generated clock period to
your system clock period to be an exact multiple. In this case (125 MHz and
1 KHz) it happens to work out nicely to be exactly 125,000. The computation
of 'FPGA_CLKS_PER_SENSOR_PERIOD' in the code below will always truncate any
fractional part. This can be fixed so that a rounding occurs, but this is
left as an exercise to the reader.
constant CLOCK_PERIOD: time := 1 us / 125; -- Define the clock period
of the FPGA clock
constant SENSOR_PERIOD: time := 1 ms;
constant FPGA_CLKS_PER_SENSOR_PERIOD: natural := CLOCK_PERIOD /
SENSOR_PERIOD;
signal Sensor_Counter: natural range 0 to FPGA_CLKS_PER_SENSOR_PERIOD;
...
process(Fpga_Clock)
constant HALF_PERIOD: natural := FPGA_CLKS_PER_SENSOR_PERIOD / 2;
begin
if rising_edge(Fpga_Clock) then
-- Create a counter of the proper period
if (Reset = '1') or (Sensor_Counter = 0) then
Sensor_Counter <= FPGA_CLKS_PER_SENSOR_PERIOD;
else
Sensor_Counter <= Sensor_Counter - 1;
end if;
-- I'm guessing you want some form of sensor clock to run at 1KHz, not
sure
if (Reset = '1') or (Sensor_Counter = 0) then
Sensor_Clock <= '0';
elsif (Sensor_Counter = HALF_PERIOD) then
Sensor_Clock <= '1';
end if;
end process;
> also what i would like to know is , is using the counter only way for
> achieving lower frequency clocks or are ther other alternatives with
> more accurecy?
In FPGAs or CPLDs, the counter is the only way that you will be able to come
up with a robust design that always works. Another approach would be PLLs
built into the part, but I don't think this would be appropriate for the
frequencies you are talking about (i.e. the 1 KHz sensor) since it is rather
needlessly generating a new clock domain that I'm sure you'll be wanting to
transfer data from into the FPGA clock domain.
Kevin Jennings
Article: 140335"KJ" <kkjennings@sbcglobal.net> wrote in message news:EikNl.15989$hc1.2627@flpi150.ffdc.sbc.com... Oops, this... > constant FPGA_CLKS_PER_SENSOR_PERIOD: natural := CLOCK_PERIOD / > SENSOR_PERIOD; Should be... constant FPGA_CLKS_PER_SENSOR_PERIOD: natural := SENSOR_PERIOD / CLOCK_PERIOD; KJArticle: 140336
On 30 Apr., 08:18, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > "Benjamin Couillard" <benjamin.couill...@gmail.com> wrote in message > > news:d4b34802-28fe-48dd-a4e8-28d812bb0f50@r13g2000vbr.googlegroups.com... > > > Hi, I've downloaded ISE 10.1 =A0and I'm now trying to install it on my > > PC. Every time I click on setup.exe, the program crashes and I get an > > error message from Windows. > > > I tried running it as an administrator, I tried running it with > > "windows xp compatability mode" and it still doesn't work. What's > > weird is that I've installed ISE 9.2 without any problems. It seems > > that Vista home is not officially supported by Xilinx since they only > > mention Vista Business on ISE 10.1 webpage. However, it should stil > > work with Vista Home. > > I recall very **vaguely** some issues running the downloaded installers o= n > XP, so assume for now and pursue it as though it were not an OS issue. It > wass long ago, and I don't recall the details. They all worked with some > trick. Something like right click/Install; or unzip and then run the > installer; or move the download to a different directory, maybe one witho= ut > spaces in the path... As I said, I don't recall, but all the 10.1 product > installers had the same problem on my system, and all installed fine with > the same trick. Well I think it IS an OS issue. I found ISE 10.x =FAnable to operate on 3 different machines now using Vista home.Article: 140337
I am searching for a simple tool to handle hdl entities similar to mentor hdl designer. no hdl synthesis required - just edit entites graphically and keep overview over the hierarchies. any idea ?Article: 140338
On May 9, 2:03=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > On May 9, 5:02=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> > wrote: > > > > > On Fri, 8 May 2009 10:01:30 -0700 (PDT), pe...@xilinx.com wrote: > > >This is not a Xilinx or Altera circuit design problem, > > > nor is it a VHDL problem. It is a systems design issue. > > > With respect, Peter, it is definitely neither a circuit > > design nor a system design problem. =A0Speaking for myself > > (and for Rick too, I'm pretty sure) I know well enough > > what the capabilities and limitations of the BRAMs are, > > and how to work with them successfully. =A0I already > > know what form of BRAM I want, and I can easily enough > > instantiate it. =A0I have already chosen a set of > > behaviours that I know are available in both Xilinx > > and Altera BRAMs. > > > But I don't want the grotesque non-portable ugliness > > of instantiated and/or wizard-generated BRAM components. > > > So I seek a way of writing VHDL and Verilog code that > > correctly describes the memories' simulation behaviour, > > at the appropriate level of abstraction, and that will > > allow a range of synthesis tools to infer correctly the > > BRAM properties that I need. =A0As has already been said by > > others, it is not hard to do this for BRAM configurations > > with only one write port. =A0As soon as you add a second > > write port, things get much more vexatious and you > > get significantly less help from the coding guidelines > > in vendor documentation. =A0There are good reasons for > > this, as have already been discussed; I made a promise > > (which I aim to keep) to find out just what can be > > done, and to write it up in a convenient vendor-neutral > > form. =A0Systems design it ain't; it's all about finding > > a valid HDL coding style that reliably gets a desired > > result out of a range of different vendors' tools. > > -- > > Jonathan Bromley, Consultant > > > DOULOS - Developing Design Know-how > > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > > The contents of this message may contain personal views which > > are not the views of Doulos Ltd., unless specifically stated. > > Why did I call it a systems problem? > The BRAM behaves like a synchronous two-port RAM should, common clock > or uncorrelated clocks, as long as you do not perform "simultaneous" > write and read operations on the same location. > Two writes with conflicting data will leave the content undefined, > while a write and a read can result in an undefined output. Two reads > are no problem. > Protecting against these system issues is quite complicated, and would > sacrifice performance. > What does the user community expect from us (Xilinx)? I'm not sure you are talking about the same problem that we are. We don't have a problem with how the block ram works. We just want to be able to use them without using instantiation, for a number of reasons. Block rams can be inferred as long as they are used in single port or pseudo dual port modes. But if they are needed with two write ports, the tools have a lot of trouble inferring a dual port block ram. The error message I got from XST 10.1 clearly showed that the tools understood that I wanted a ram with two write ports, but it could not figure out that I wanted it to use the block ram. Or am I missing something about your statements that affect this issue? Actually, the VHDL description of a block ram that uses two processes to write to the same memory also has undefined behavior. If both processes write to the same location using the same clock edge, it is undefined which process will run first and which will run second; so the result written to the block ram is undefined... maybe not in the same way as the hardware, but it is still undefined. RickArticle: 140339
"andip1982" <andreasp1982@arcor.de> wrote in message news:3dfee53c-de02-48f3-8e73-282ed26d6a45@t11g2000vbc.googlegroups.com... On 30 Apr., 08:18, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > "Benjamin Couillard" <benjamin.couill...@gmail.com> wrote in message > > news:d4b34802-28fe-48dd-a4e8-28d812bb0f50@r13g2000vbr.googlegroups.com... > > > Hi, I've downloaded ISE 10.1 and I'm now trying to install it on my > > PC. Every time I click on setup.exe, the program crashes and I get an > > error message from Windows. > > > I tried running it as an administrator, I tried running it with > > "windows xp compatability mode" and it still doesn't work. What's > > weird is that I've installed ISE 9.2 without any problems. It seems > > that Vista home is not officially supported by Xilinx since they only > > mention Vista Business on ISE 10.1 webpage. However, it should stil > > work with Vista Home. > > I recall very **vaguely** some issues running the downloaded installers on > XP, so assume for now and pursue it as though it were not an OS issue. It > wass long ago, and I don't recall the details. They all worked with some > trick. Something like right click/Install; or unzip and then run the > installer; or move the download to a different directory, maybe one > without > spaces in the path... As I said, I don't recall, but all the 10.1 product > installers had the same problem on my system, and all installed fine with > the same trick. Well I think it IS an OS issue. I found ISE 10.x únable to operate on 3 different machines now using Vista home. ======== Maybe. They do take care teo specifically say XP Business in the system requirements. I also rediscovered how some installers dislike spaces in path names. I went through several tens of gigabytes of upgrades here recently.Article: 140340
On Sat, 9 May 2009 12:41:34 -0700 (PDT), andip1982 <andreasp1982@arcor.de> wrote: >I am searching for a simple tool to handle hdl entities similar to >mentor hdl designer. no hdl synthesis required - just edit entites >graphically and keep overview over the hierarchies. You say "no synthesis required", but in fact what you're asking for is synthesis of all but the leaf instances (i.e. those that don't themselves contain any instances). You can easily do this for simple cases, but if someone is using the full power of Verilog or VHDL generates to create an interesting hierarchy, nothing short of full processing of the language will do. In fact I think you will find that the big-name FPGA tools (Quartus, ISE) provide pretty much what you need, for low or zero cost. You can edit schematics (perish the thought) and create an HDL netlist from them. Good luck. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 140341
Rick,
I hope this can help...
below you can find the code to infer dual port-ram with
both port sharing the same clock.
I suppose the secret could be using a shared variable (instead of a
signal) as RAM...
regards
Sandro
entity ramInference is
generic (
g_data_w : natural := 9;
g_addr_w : natural := 11
);
port (
i_clkA : in std_logic;
--i_clkB : in std_logic;
i_enA : std_logic;
i_weA : std_logic;
i_addrA : in std_logic_vector (g_addr_w - 1 downto 0);
i_dataA : in std_logic_vector (g_data_w - 1 downto 0);
o_dataA : out std_logic_vector (g_data_w - 1 downto 0);
i_enB : std_logic;
i_weB : std_logic;
i_addrB : in std_logic_vector (g_addr_w - 1 downto 0);
i_dataB : in std_logic_vector (g_data_w - 1 downto 0);
o_dataB : out std_logic_vector (g_data_w - 1 downto 0)
);
end ramInference;
architecture Behavioral of ramInference is
constant c_ram_sz : natural := 2**(g_addr_w);
type t_ram is array (c_ram_sz - 1 downto 0) of
std_logic_vector (g_data_w - 1 downto 0);
shared variable v_ram : t_ram := (
1 => X"05",
2 => X"08",
3 => X"1A",
-- ...
others => X"00"
);
begin
p_portA : process (i_clkA)
begin
if rising_edge(i_clkA) then
if (i_enA = '1') then
-- READ FIRST
o_dataA(g_data_w - 1 downto 0) <= v_ram(conv_integer
(i_addrA));
-- WRITE AFTER
if (i_weA = '1') then
v_ram(conv_integer(i_addrA)) := i_dataA(g_data_w - 1 downto
0);
end if;
end if;
end if;
end process;
p_portB : process (i_clkA)
begin
if rising_edge(i_clkA) then
if (i_enB = '1') then
-- WRITE FIRST
if (i_weB = '1') then
v_ram(conv_integer(i_addrB)) := i_dataB(g_data_w - 1 downto
0);
end if;
-- READ AFTER
o_dataB(g_data_w - 1 downto 0) <= v_ram(conv_integer
(i_addrB));
end if;
end if;
end process;
end Behavioral;
Article: 140342The BRAM does not have the necessary dual address decoders. The best option is to clock at half speed and multiplex. Read before write is most usual.Article: 140343
On May 9, 2:26=A0pm, Jacko <jackokr...@gmail.com> wrote: > The BRAM does not have the necessary dual address decoders. The best > option is to clock at half speed and multiplex. Read before write is > most usual. All Xilinx BRAMs have dual address decoders, and each port also has the option of read before or after write or retain previous output. It seems there is no argument about the hardware, but there is about the software... Peter AlfkeArticle: 140344
On May 10, 12:15=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > All Xilinx BRAMs have dual address decoders, and each port also has > the option of read before or after write or retain previous output. > It seems there is no argument about the hardware, but there is about > the software... > Peter Alfke Peter, This time... (quite) no argument about the software too (see my previous post). XST (your software [xilinx]) infers the bram with two r/w ports both with "READ FIRST" and with "WRITE FIRST" options... Maybe the only software (vhdl) argument could be "how to infer dual port BRAM with different bus sizes for the two ports" regards SandroArticle: 140345
On May 9, 4:31=A0pm, Sandro <sdro...@netscape.net> wrote: > > Peter, > This time... (quite) no argument about the software too (see my > previous post). > XST (your software [xilinx]) infers the bram with two r/w ports both > with "READ FIRST" and with "WRITE FIRST" options... > > Maybe the only software (vhdl) argument could be "how to infer dual > port BRAM with > different bus sizes for the two ports" > > regards > Sandro Thought I would chime in on some of the comments and observations from this thread. Starting with the most recent comment, if you need different port widths in either the read vs. write of the same port or different widths on the dual port, you do need to instantiate. Neither XST, Synplify or Precision support RAMs with different port widths. I can comment from the XST side that we have investigated this and plan to some day offer this however to date, have not been able to include this capability. As Sandro explains, you should be able to infer a common clock dual port RAM (assuming same port widths) in any of the READ_FIRST, WRITE_FIRST or NO_CHANGE modes. It is fairly straightforward in verilog to code this however for VHDL as explained, you do need to use a shared variable to accomplish this. I am more familiar with Verilog than VHDL but my understanding is that the shared variable is necessary for proper simulation when accessing the same array at the same time. In terms of coding examples for these RAMs, most of the coding examples can be found in the Xilinx Language Templates which are accessible from Xilinx Project Navigator. Open the Templates and look in VHDL or Verilog --> Synthesis Constructs --> Coding Examples -- > RAM to see several examples. In the Single-Port descriptions you can see the differences between READ_FIRST, WRITE_FIRST and NO_CHANGE mode however unfortunately for the dual port not all have been adapted there but in theory should work. I will see if in 11.2 we can get the templates updated to include all of the dual port examples for these. One other note, if you are inferring a BRAM in which you never plan to read from the same port at the time you are writing, describe NO_CHANGE mode. It will save power but not many realize this. In terms of memory collisions (writing to the same memory address on a dual port RAM as either reading or writing on the other) this described in the device User Guides and the Synthesis and Simulation Design Guide so I hope that most understand what it is and what should be done to avoid them however as for inferring dual-port BRAM, you do need to heed more caution. A behavioral RTL simulation will not alert or model a collision so you can very well simulate a collision behaviorally and get a seemingly valid result but the implementation can give something different. This is not covered by static timing analysis as this is a dynamic situation. It can be covered and alerted by timing simulation however many choose not to do timing simulations so in lieu of that some synthesis tools have decided to arbitrate the access to the same memory locations with additional logic around the BRAM. Both Synplicity and Precision do this however XST does not. Most people who are aware of this, disable the addition of the collision avoidance logic using a synthesis attribute as it can slow the RAM down, add more resources and add more power to the FPGA design and in many cases is not needed however if you do disable this, you need to take extra care to ensure an undetected collision will not give undesired results in your design. I too try to avoid instantiation of BRAM however one advantage it does give you is it will alert you to a memory collision as it is modeled in the UNISIM. As mentioned before a timing simulation (no matter how the RAM was entered) can also detect this. In system testing, can not detect this. Reason being, collisions are as unpredictable as a timing error and while a system may behave one way in one device in one environmental condition (temperature or voltage) during a collision, it may behave differently in another device or under a different environmental condition) so I would not trust in-system testing to this any more than I would a timing violation. Hopefully this clears up some of the issues identified in this thread. I often do infer RAMs in my designs however there are certain circumstances (such as different port widths) that necessitate instantiation so we are still not in a full RTL world when it comes to RAMs. However more situations than most know can be inferred with relative ease (i.e. dual-port, byte enables, read modes, initialization from an external file, all can be inferred now). Regards, -- Brian Philofsky -- Xilinx ApplicationsArticle: 140346
On May 10, 6:00=A0am, Brian <scubabr...@gmail.com> wrote: > On May 9, 4:31=A0pm, Sandro <sdro...@netscape.net> wrote: > > > > > Peter, > > This time... (quite) no argument about the software too (see my > > previous post). > > XST (your software [xilinx]) infers the bram with two r/w ports both > > with "READ FIRST" and with "WRITE FIRST" options... > > > Maybe the only software (vhdl) argument could be "how to infer dual > > port BRAM with > > different bus sizes for the two ports" > > > regards > > Sandro > > Thought I would chime in on some of the comments and observations from > this thread. =A0Starting with the most recent comment, if you need > different port widths in either the read vs. write of the same port or > different widths on the dual port, you do need to instantiate. > Neither XST, Synplify or Precision support RAMs with different port > widths. =A0I can comment from the XST side that we have investigated > this and plan to some day offer this however to date, have not been > able to include this capability. > > As Sandro explains, you should be able to infer a common clock dual > port RAM (assuming same port widths) in any of the READ_FIRST, > WRITE_FIRST or NO_CHANGE modes. =A0It is fairly straightforward in > verilog to code this however for VHDL as explained, you do need to use > a shared variable to accomplish this. =A0I am more familiar with Verilog > than VHDL but my understanding is that the shared variable is > necessary for proper simulation when accessing the same array at the > same time. =A0In terms of coding examples for these RAMs, most of the > coding examples can be found in the Xilinx Language Templates which > are accessible from Xilinx Project Navigator. =A0Open the Templates and > look in VHDL or Verilog --> Synthesis Constructs --> Coding Examples --> = RAM to see several examples. =A0In the Single-Port descriptions you > > can see the differences between READ_FIRST, WRITE_FIRST and NO_CHANGE > mode however unfortunately for the dual port not all have been adapted > there but in theory should work. =A0I will see if in 11.2 we can get the > templates updated to include all of the dual port examples for these. > One other note, if you are inferring a BRAM in which you never plan to > read from the same port at the time you are writing, describe > NO_CHANGE mode. =A0It will save power but not many realize this. > > In terms of memory collisions (writing to the same memory address on a > dual port RAM as either reading or writing on the other) this > described in the device User Guides and the Synthesis and Simulation > Design Guide so I hope that most understand what it is and what should > be done to avoid them however as for inferring dual-port BRAM, you do > need to heed more caution. =A0A behavioral RTL simulation will not alert > or model a collision so you can very well simulate a collision > behaviorally and get a seemingly valid result but the implementation > can give something different. =A0This is not covered by static timing > analysis as this is a dynamic situation. =A0It can be covered and > alerted by timing simulation however many choose not to do timing > simulations so in lieu of that some synthesis tools have decided to > arbitrate the access to the same memory locations with additional > logic around the BRAM. =A0Both Synplicity and Precision do this however > XST does not. =A0Most people who are aware of this, disable the addition > of the collision avoidance logic using a synthesis attribute as it can > slow the RAM down, add more resources and add more power to the FPGA > design and in many cases is not needed however if you do disable this, > you need to take extra care to ensure an undetected collision will not > give undesired results in your design. =A0I too try to avoid > instantiation of BRAM however one advantage it does give you is it > will alert you to a memory collision as it is modeled in the UNISIM. > As mentioned before a timing simulation (no matter how the RAM was > entered) can also detect this. In system testing, can not detect > this. =A0Reason being, collisions are as unpredictable as a timing error > and while a system may behave one way in one device in one > environmental condition (temperature or voltage) during a collision, > it may behave differently in another device or under a different > environmental condition) so I would not trust in-system testing to > this any more than I would a timing violation. > > Hopefully this clears up some of the issues identified in this > thread. =A0I often do infer RAMs in my designs however there are certain > circumstances (such as different port widths) that necessitate > instantiation so we are still not in a full RTL world when it comes to > RAMs. =A0However more situations than most know can be inferred with > relative ease (i.e. dual-port, byte enables, read modes, > initialization from an external file, all can be inferred now). > > Regards, > > -- =A0Brian Philofsky > -- =A0Xilinx Applications Brian, thanks for your answer ... you avoided me to waste time trying to figure out how the ram can be represented (in vhdl) as two array with "different geometry" (read dual port with different bus sizes). Peter Alfke wrote: > ... > What does the user community expect from us (Xilinx)? > ... (...winking to Peter) that is what the user community expect from you (Xilinx) ;-) regards SandroArticle: 140347
Hi I am looking to get some info on implementing arbitrary combinational functions in large designs using block rams (BRAMs). The target is an emulation platform using Virtex 4 fpgas For example assign x = ^a where a is an 8 bit input for example. in normal fpga synthesis will use LUTS. However I can declare a memory as reg [255:0] lookuptable_for_bitwise_xor_mem; always@(a) begin x <= lookuptable_for_bitwise_xor_mem[a]; end I would have pre loaded lookuptable_for_bitwise_xor_mem with the truth table for 8 input bitwise XOR. Note that this is just one example. The advantage is that I use little LUTs and only Block RAMs (which are unused otherwise), therefore rducing area. If there is another assign that takes a bitwise xor of 8 bit vector, I can use the same ROM and reuse the ROM. Example: assign x = ^a assign y = ^b where a, b is an 8 bit input for example. becomes always@(a or b) begin x <= lookuptable_for_bitwise_xor_mem[a]; y <= lookuptable_for_bitwise_xor_mem[b]; end I am basically trying to use BRAMs that are unused anyway - there are more than 300 BRAMs per Virtex 4 FPGA each of 16K. Now the question is - is this a feasible way to reduce LUTs and thereby area? . -AndyArticle: 140348
On May 10, 8:51=A0am, anand <writean...@gmail.com> wrote: > Hi > > I am looking to get some info on implementing arbitrary combinational > functions in large designs using block rams (BRAMs). The target is an > emulation platform using Virtex 4 fpgas > > For example > > assign x =3D ^a > =A0 where a is an 8 bit input for example. > > in normal fpga synthesis will use LUTS. > > However I can declare a memory as > > reg [255:0] lookuptable_for_bitwise_xor_mem; > > always@(a) begin > > x <=3D =A0lookuptable_for_bitwise_xor_mem[a]; > end > > I would have pre loaded =A0lookuptable_for_bitwise_xor_mem with the > truth table for 8 input bitwise XOR. > > Note that this is just one example. > > The advantage is that I use little LUTs and only Block RAMs (which are > unused otherwise), therefore rducing area. > > If there is another assign that takes a bitwise xor of 8 bit vector, I > can use the same ROM and reuse the ROM. > > Example: > > assign x =3D ^a > assign y =3D ^b > =A0where a, b is an 8 bit input for example. > > becomes > > always@(a or b) begin > > x <=3D =A0lookuptable_for_bitwise_xor_mem[a]; > y <=3D =A0lookuptable_for_bitwise_xor_mem[b]; > > end > > =A0I am basically trying to use BRAMs that are unused anyway - there are > more than 300 BRAMs per Virtex 4 FPGA each of 16K. > > Now the question is - is this a feasible way to reduce LUTs and > thereby area? . > > -Andy The double use needs two address decoders, and so does not work as far as I am aware. The same table would have to be duplicated in two BRAMs. cheers jackoArticle: 140349
anand wrote: > Hi <snip> > I am basically trying to use BRAMs that are unused anyway - there are > more than 300 BRAMs per Virtex 4 FPGA each of 16K. > > Now the question is - is this a feasible way to reduce LUTs and > thereby area? . (warning : it's just a guess, not even an opinion or experiment result) It helps, I presume. You should target the complex logic operations, or (if there are enough address pins) you can even provide a quite fast "logic reduction" (the OR or AND of many inputs). However the overall speed will be different, and not necessarily faster. This is because LUTs are regularly spread all over the chip, but BRAMs are in certain places. So place&route will be more constrained than before, may resulting in slightly longer wires and slower signals. OTOH if your design is already filling the FPGA, and speed is not an issue, it looks like a good method. > -Andy yg -- http://ygdes.com / http://yasep.org
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