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
Xilinx has these tools availalbe, called System Generator for DSP that is a toolbox in Simulink environment. JTAG cosim (for hardware cosimulation) is one of the strongest reasons why customers use it. jfh wrote: > Hi, > > I imagine it would be pretty heavy in terms of communication but I have > read and not investigated the fact that some hardware in the loop > simulation was availbale when doing DSP functions with Simulink. I was > wondering wether there wasn't a similar mechanism for other types of > application. > > Best regards, > > JF Hasson > > Andy a =E9crit : > > > Co-simulation with real hardware would take a LOT of software work for > > the API calls from the simulator to the hardware, and would require a > > pretty good interface between the computer runninng the simulation and > > the hardware. > > > > You might try creating your testbenches such that they are > > synthesizable, and load them into the chip too (assuming there's enough > > room). You can't use assert statements or text io, but you could set > > spare outputs that could be monitored with a scope or logic analyzer. > > > > With built-in wrap-around interfaces, the processor in the design could > > run a lot of tests. > > > > Andy > > > > > > jfh wrote: > > > Hi, > > > > > > I am presently involved in a project dealing with a pretty large desi= gn > > > in a Stratix II GX chip with a Nios II processor. Is there anyway to > > > perform hardware in the loop simulation where the Nios II would be > > > running on a board while modelsim is simulating the design ? Does > > > anyone have an advice as to how simulation times could be improved wh= en > > > involving Nios II processor ? > > >=20 > > > Best regards, > > >=20 > > > JF HassonArticle: 112876
PeteS wrote:
> Martin Thompson wrote:
> > burn.sir@gmail.com writes:
> >
> > {about Lattice}
> >> They use Synplify (and Precision) for synthesis. Not as good as Quartus
> >> or XST, but it does the job. Might need some tweaking however when
> >> inferring memories.
> >>
> >
> > Can you provide more details? My experience to date has been that
> > Synplify is better than XST, especially on runtime, and almost all the
> > time on size & speed.
> >
> > Cheers,
> > Martin
> >
>
> Thanks for the answers, chaps.
>
> I can now be a little more confident of using the devices. I have the
> time to do a migration (well, a clean new design as it happens) if I
> start now, and most of that extra time should (hopefully) be merely tool
> related.
>
> I'll talk to my friendly vendor about pricing etc., tomorrow.
>
> That doesn't mean I won't use the other brands; in this particular case
> it may make more sense to use brand L.
>
> Cheers
>
> PeteS
I've been using Xilinx parts for some time, and started using the ECP
series from Lattice recently. So far there have been some bumps in
the implementation software (crash during P&R, timing anomalies),
but the latest tools version appears to be more solid. There are still
issues with "TRACE" (timing analysis) and related clocks. For instance
when I have a 200 MHz clock at 0 phase and another at 270 degrees,
I would expect a signal traveling from the 0 phase domain to the
270 degree domain to have 3/4 clock period or 3.75 nS from
clock edge to clock edge (less uncertainties, etc.). TRACE seems
to think the signal should be allowed 1 3/4 periods or 8.75nS.
Additionally if I place a "MULTICYCLE" constraint from the 0
phase clock to the 270 degrees phase clock, it is ignored and
the 8.75nS constraint is still used. In my case the 270 degree
clock is for output registers only, so I don't need a real
PERIOD constraint on it. Thus I managed to trick the TRACE
tool into giving me the 3.75nS clock to clock path by setting
the PERIOD to 2.143nS on the 270 degree clock. Strangely
the tools seem happy with this even though it should know that
the two clocks should be at the same frequency.
Also I've noticed the documentation is still a bit weak, but getting
better. It's currently a mix of HTML and .pdf files. Information on
library components is spread among a number of technical notes,
although a complete listing (without full details) is available for
each part series.
If you've worked with Xilinx you'll recognize the tool flow because
both tools were developed at NeoCAD. Lattice's GUI has a lot
of similarity to ISE, with a process flow window. It took me a
while to find out that not all settings in the flow can be reached
by right clicking an object and selecting properties. TRACE
parameters are only available through the menu bar.
For programming, ispVM seems simpler to use than iMPACT. Once
you get the hang of it you'll like the features like being able to have
more than one setup open at a time.
I can't really comment on Symplify vs. XST, because I'm only
working on new designs with Lattice, so I didn't really compare
apples to apples. My gut feeling is that it's at least as good
as the recent release of XST, which is already much improved
over the version 6 XST.
If you don't already have a non-branded ModelSim seat, the
base tools (not free web version, but still inexpensive) come
with a Lattice-branded ModelSim license that doesn't have
the annoying slow-down you get with the X-brand license.
I'm assuming it nails you by stopping to work at some
design size, but I haven't run into that yet.
Finally I think you'll find that Lattice is very aggressive with
pricing. Like I said we've been using Xilinx for some time
now, and we don't pay the web price for their parts. Still
for the same functionality it seems Lattice can offer significant
savings over Xilinx.
Article: 112877
Hi,
I am learning FPGA by a DSP book (1st edition) written by Uew
Meyer_Baese. There is an example about 16 bit adder with detailed
timing parameters, such as: tco=0.2 ns, tcgen=1.5ns tcico=0.3ns,
tsamerow=2.9ns, tLUT=1.9ns and tsu=2.7ns. The fmax of that 16 bit adder
is 74.6 MHz I think it is EPF10K20RC240-4 from the context.
In my practice project, I can only see the IC(interconect) and CELL
delay timing parameters from the timing closure floorplan. Because the
fmax I get is lower (only 59.52 MHz from timing analyzer) than that in
the book, I want to know the difference. The purpose is I want to be
ensure whether I get the fast 16 bit adder. BTW, I post my code below.
Because the timing parameters give tco etc., I use register at the
input and output ports.
Could you help me? Thanks in advance.
LIBRARY lpm;
USE lpm.lpm_components.ALL;
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_arith.ALL;
ENTITY add16 IS
GENERIC (WIDTH : INTEGER := 16; -- Total bit width
ONE : INTEGER := 1); -- 1 bit for carry reg.
PORT (x,y : IN STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0);
-- Inputs
sum : OUT STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0);
clk : IN STD_LOGIC);
END add16;
ARCHITECTURE flex OF add16 IS
SIGNAL sum0, q2, q1 -- LSBs of inputs
: STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0);
BEGIN
reg_1: lpm_ff -- Save LSBs of x+y and carry
GENERIC MAP ( LPM_WIDTH => WIDTH )
PORT MAP ( data => x, q => q1,clock => clk );
reg_2: lpm_ff
GENERIC MAP ( LPM_WIDTH => WIDTH )
PORT MAP ( data => y, q => q2, clock => clk );
-------------- First stage of the adder ------------------
add_1: lpm_add_sub -- Add LSBs of x and y
GENERIC MAP ( LPM_WIDTH => WIDTH,
LPM_REPRESENTATION => "UNSIGNED",
LPM_DIRECTION => "ADD")
PORT MAP ( dataa => q1, datab => q2,
result => sum0);
reg_3: lpm_ff
GENERIC MAP ( LPM_WIDTH => WIDTH )
PORT MAP ( data => sum0, q => sum, clock => clk );
END flex;
Article: 112878Hi, I am not sure if anyone has done this here. I am looking for anyone who could share their thesis especially on image processing on fpga/dsp/asic. Thank you.Article: 112879
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:newscache$j4li9j$qze$1@lbox.itee.uq.edu.au... > Hi Clark, > > Anonymous wrote: > > > I have a xilinx v4 project running mv linux 2.6.10. I have a custom > > peripheral I made that includes DMA on the opb bus and is therefore > > master/slave. The SDRAM that the linux .elf file loads to/boots from is also > > on the opb. Unless I disconnect the custom peripheral linux dies at > > "uncompressing linux...". > > > > I believe this means that there are data errors from the sdram, but > > everything works fine stand-alone. I know the dma isn't running, for > > example, and I've made sure to reset every other register related to that > > peripheral but linux just won't boot unless I disconnect it. > > Can you run the auto-generated TestApp_Memory sucessfully when your peripheral > is in the system? > > More broadly, are you able to confirm that your core is behaving itself on the > OPB bus? Either through simulation or by running standalone testslike > TestApp_Memory etc? > > John Yes, all my stand alone applications work fine including one that DMAs data from the offending peripheral to the main memory where the linux .elf is loaded. Thanks, ClarkArticle: 112880
whats your project? you can search through lots of online theses through your university library system. I can send you mine if you like, whats your email? I can answer some questions too... Just cite my work if you use it. my thesis is titled EMBEDDED PATTERN RECOGNITION WITH FIELD PROGRAMMABLE GATE ARRAYS thanks, --geoff wallge@gmail.com awa wrote: > Hi, > > I am not sure if anyone has done this here. > > I am looking for anyone who could share their thesis especially on > image processing on fpga/dsp/asic. > > Thank you.Article: 112881
I am interested in this... Send me more information and I will see if I can be of service... --geoff wallge@gmail.com aiiadict@gmail.com wrote: > looking for someone to program an FPGA to interface with > a mitsubishi camera chip... definitely not top dollar, but if > you want to practice your skills and make a few bucks, send > an email. > > > RArticle: 112882
After doing a full compile, open the "Timing Analysis" report folder. Under that report, look for the "Clock Setup: <name>" panel where <name> is the name of you clock signal. From that report, select any interested row and then using the right mouse button (button-2), select "List Path". This command will report the full path detail in the form of a message in your message window. You can do this operation on any of the other timing report panels. Also note that when you did the full compiled, the Classic Timing Analyzer automatically did a List path operation on the worst case Fmax, Tsu, Th and Tco paths. BTW, make sure you have a timing constraint if you want the fitter to do its best. Go to the "Timing Analysis Settings" panel and create a clock requirement for your clock. For example, it can be the 75MHz the book gives. For more, see: http://www.altera.com/support/software/quartus2/timing/sof-qts-timing.html -David On Nov 30, 6:45 am, "fl" <rxjw...@gmail.com> wrote: > Hi, > I am learning FPGA by a DSP book (1st edition) written by Uew > Meyer_Baese. There is an example about 16 bit adder with detailed > timing parameters, such as: tco=0.2 ns, tcgen=1.5ns tcico=0.3ns, > tsamerow=2.9ns, tLUT=1.9ns and tsu=2.7ns. The fmax of that 16 bit adder > is 74.6 MHz I think it is EPF10K20RC240-4 from the context. > > In my practice project, I can only see the IC(interconect) and CELL > delay timing parameters from the timing closure floorplan. Because the > fmax I get is lower (only 59.52 MHz from timing analyzer) than that in > the book, I want to know the difference. The purpose is I want to be > ensure whether I get the fast 16 bit adder. BTW, I post my code below. > Because the timing parameters give tco etc., I use register at the > input and output ports. > > Could you help me? Thanks in advance. > > LIBRARY lpm; > USE lpm.lpm_components.ALL; > > LIBRARY ieee; > USE ieee.std_logic_1164.ALL; > USE ieee.std_logic_arith.ALL; > > ENTITY add16 IS > GENERIC (WIDTH : INTEGER := 16; -- Total bit width > ONE : INTEGER := 1); -- 1 bit for carry reg. > PORT (x,y : IN STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > -- Inputs > sum : OUT STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > clk : IN STD_LOGIC); > END add16; > > ARCHITECTURE flex OF add16 IS > SIGNAL sum0, q2, q1 -- LSBs of inputs > : STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > BEGIN > reg_1: lpm_ff -- Save LSBs of x+y and carry > GENERIC MAP ( LPM_WIDTH => WIDTH ) > PORT MAP ( data => x, q => q1,clock => clk ); > reg_2: lpm_ff > GENERIC MAP ( LPM_WIDTH => WIDTH ) > PORT MAP ( data => y, q => q2, clock => clk ); > -------------- First stage of the adder ------------------ > add_1: lpm_add_sub -- Add LSBs of x and y > GENERIC MAP ( LPM_WIDTH => WIDTH, > LPM_REPRESENTATION => "UNSIGNED", > LPM_DIRECTION => "ADD") > PORT MAP ( dataa => q1, datab => q2, > result => sum0); > reg_3: lpm_ff > GENERIC MAP ( LPM_WIDTH => WIDTH ) > PORT MAP ( data => sum0, q => sum, clock => clk ); > > END flex;Article: 112883
Antti wrote: > leevv schrieb: > > > Hi Antti, > > What ver of MPMC2 are you using? > > They fix OPB related bug in the october release. > > > release 10202006 > october 20th? > > BUG : PRESENT, OPB just doesnt work > > Antti We had the problem with 2 ppc trying to share opb bus through the internal PLB to OPB bridge. On the august mpmc2 release, PPCs just hang when had simultaneous access to the same OPB peripheral. We used workaround with standard external PLB2OPB bridge. THen we test new version (october) and found that this problem gone. But we didn't switch our design to the new core and still using august ver with workaround (don't want to introduce new bugs) I found that mpmc2 design team is more or less cooperative when you report the bugs. Lately they reguire to open webcase, but before I just sent them email directly and they did respond quickly.Article: 112884
fl, Meyer Baese was my teacher at FSU, and he taught my class using the DSP w/ FPGAs book he wrote. Its a small world... If you want to run an adder really fast you can instantiate an adder component from the altera mega function tool within the arithmetic components subsection. >From inside the megafunction wizard GUI you can select the level of pipelining within the adder. So you can select anywhere from 1 to N clock cycles of delay. The more delay, the faster you can clock the adder. As far as timing parameters, you can see all the timing (slack, etc) from one critical path to another within the timing subsection of the compilation report after you compile your design in quartus II. --geoff fl wrote: > Hi, > I am learning FPGA by a DSP book (1st edition) written by Uew > Meyer_Baese. There is an example about 16 bit adder with detailed > timing parameters, such as: tco=0.2 ns, tcgen=1.5ns tcico=0.3ns, > tsamerow=2.9ns, tLUT=1.9ns and tsu=2.7ns. The fmax of that 16 bit adder > is 74.6 MHz I think it is EPF10K20RC240-4 from the context. > > In my practice project, I can only see the IC(interconect) and CELL > delay timing parameters from the timing closure floorplan. Because the > fmax I get is lower (only 59.52 MHz from timing analyzer) than that in > the book, I want to know the difference. The purpose is I want to be > ensure whether I get the fast 16 bit adder. BTW, I post my code below. > Because the timing parameters give tco etc., I use register at the > input and output ports. > > Could you help me? Thanks in advance. > > > > LIBRARY lpm; > USE lpm.lpm_components.ALL; > > LIBRARY ieee; > USE ieee.std_logic_1164.ALL; > USE ieee.std_logic_arith.ALL; > > ENTITY add16 IS > GENERIC (WIDTH : INTEGER := 16; -- Total bit width > ONE : INTEGER := 1); -- 1 bit for carry reg. > PORT (x,y : IN STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > -- Inputs > sum : OUT STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > clk : IN STD_LOGIC); > END add16; > > ARCHITECTURE flex OF add16 IS > SIGNAL sum0, q2, q1 -- LSBs of inputs > : STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > BEGIN > reg_1: lpm_ff -- Save LSBs of x+y and carry > GENERIC MAP ( LPM_WIDTH => WIDTH ) > PORT MAP ( data => x, q => q1,clock => clk ); > reg_2: lpm_ff > GENERIC MAP ( LPM_WIDTH => WIDTH ) > PORT MAP ( data => y, q => q2, clock => clk ); > -------------- First stage of the adder ------------------ > add_1: lpm_add_sub -- Add LSBs of x and y > GENERIC MAP ( LPM_WIDTH => WIDTH, > LPM_REPRESENTATION => "UNSIGNED", > LPM_DIRECTION => "ADD") > PORT MAP ( dataa => q1, datab => q2, > result => sum0); > reg_3: lpm_ff > GENERIC MAP ( LPM_WIDTH => WIDTH ) > PORT MAP ( data => sum0, q => sum, clock => clk ); > > END flex;Article: 112885
Symon, First, you are correct that the power is spread over a wider frequency band by 'spread spectrum', and is in no way reduced (the same power, either way). It that sense, it is a sham, as the noise floor just rises. Or, if you have a wideband channel, the spread spectrum is just a real pain, as it is all there, audible (or visible), interfering. Most of the spread spectrum clock generators use a triangular wideband FM modulation, so they are really very annoying if your receiver is wide enough to hear it (it just howls). "True" ss would be a psuedo noise signal, which is less annoying, but still interference! These ss clock generatorss do "fool" the FCC and CE test setups into believing they are "not there." As far as a police or fire radio is concerned, they are not 'there', and will not interfere. Second, Xilinx was always careful to note that specific implementations of PLLs might not deliver all the benefits that should be there, due to limitations with sharing common ground, and power, adjacent circuit interference, etc. Not that we are able to be immune from everything, but at least by studying the competition, and knowing the weaknesses, we could set the goal to exceed their performance (which we did). Third, the "normal" spread spectrum is unable to cause a DCM to lose lock, or prevent it from locking (as you so rightly point out). We just did not want to have to characterize a dozen or so spread spectrum clock generators and our DCM to PROVE it. Since the 300 ps spec applies to the clock edges that are critical (which are 6 clocks apart in V2, V2P, and 36 clocks apart in V4, V5), it is tough to be absolutely sure that in 36 clock, 300 ps will never accrue. Are you sure? If so, then use our DCM with your spread spectrum clock. Austin PS: Drove by a hybrid electric vehicle yesterday, and it completely wiped out a low power distant FM radio station (went from full quieting stereo music to loud hash and buzzing!). Cars do not have to meet FCC or CE rules. A real sham. (and a shame)Article: 112886
Thank you very much. The problem is that I cannot get the claimed performance of the example in that book. For the add_1p.vhd, 15-bit (which said it could be 97.08 MHz in the book), I can only get 69.87 MHz fmax. In this example, I don't modify the code at all. Even I add the timing constraint, the result is the same. It is really bizarre. For the post code, it was an exercise with the given results. I don't know where it is wrong. Anyone could test the best performance of the post code? wallge wrote: > fl, > > Meyer Baese was my teacher at FSU, and > he taught my class using the DSP w/ FPGAs book he wrote. > Its a small world... > > If you want to run an adder really fast you can instantiate an adder > component > from the altera mega function tool within the arithmetic components > subsection. > >From inside the megafunction wizard GUI you can select the level of > pipelining > within the adder. So you can select anywhere from 1 to N clock cycles > of delay. > The more delay, the faster you can clock the adder. > > As far as timing parameters, you can see all the timing (slack, etc) > from one critical path to another > within the timing subsection of the compilation report after you > compile your design in quartus II. > > > --geoff > > fl wrote: > > Hi, > > I am learning FPGA by a DSP book (1st edition) written by Uew > > Meyer_Baese. There is an example about 16 bit adder with detailed > > timing parameters, such as: tco=0.2 ns, tcgen=1.5ns tcico=0.3ns, > > tsamerow=2.9ns, tLUT=1.9ns and tsu=2.7ns. The fmax of that 16 bit adder > > is 74.6 MHz I think it is EPF10K20RC240-4 from the context. > > > > In my practice project, I can only see the IC(interconect) and CELL > > delay timing parameters from the timing closure floorplan. Because the > > fmax I get is lower (only 59.52 MHz from timing analyzer) than that in > > the book, I want to know the difference. The purpose is I want to be > > ensure whether I get the fast 16 bit adder. BTW, I post my code below. > > Because the timing parameters give tco etc., I use register at the > > input and output ports. > > > > Could you help me? Thanks in advance. > > > > > > > > LIBRARY lpm; > > USE lpm.lpm_components.ALL; > > > > LIBRARY ieee; > > USE ieee.std_logic_1164.ALL; > > USE ieee.std_logic_arith.ALL; > > > > ENTITY add16 IS > > GENERIC (WIDTH : INTEGER := 16; -- Total bit width > > ONE : INTEGER := 1); -- 1 bit for carry reg. > > PORT (x,y : IN STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > > -- Inputs > > sum : OUT STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > > clk : IN STD_LOGIC); > > END add16; > > > > ARCHITECTURE flex OF add16 IS > > SIGNAL sum0, q2, q1 -- LSBs of inputs > > : STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > > BEGIN > > reg_1: lpm_ff -- Save LSBs of x+y and carry > > GENERIC MAP ( LPM_WIDTH => WIDTH ) > > PORT MAP ( data => x, q => q1,clock => clk ); > > reg_2: lpm_ff > > GENERIC MAP ( LPM_WIDTH => WIDTH ) > > PORT MAP ( data => y, q => q2, clock => clk ); > > -------------- First stage of the adder ------------------ > > add_1: lpm_add_sub -- Add LSBs of x and y > > GENERIC MAP ( LPM_WIDTH => WIDTH, > > LPM_REPRESENTATION => "UNSIGNED", > > LPM_DIRECTION => "ADD") > > PORT MAP ( dataa => q1, datab => q2, > > result => sum0); > > reg_3: lpm_ff > > GENERIC MAP ( LPM_WIDTH => WIDTH ) > > PORT MAP ( data => sum0, q => sum, clock => clk ); > > > > END flex;Article: 112887
bbethlehem wrote: > I am also trying to get profiling to work using the PPC405. I have > read the app note, but I am still rather confused....it says we can use > the PIT timer, but do we still need to do all the initialization of > interrupts and timers? If so, did you just do this in your application? > Do you have any sample code I could look at? > I did this a while ago, so I don't remember all the details. Here are my notes on the subject: 1. Software Platform Settings: enable_intrusive_sw_profiling 2. Recompile bsp 3. Compiler Options: -O1, Other Compiler Options: -pg 4. Disable interrupts, poll_next_frame 5. Change top of mem mpeg.ld to 0x1c00000 6. Recompile application xmd: profile -config profile_mem 0x1c00000 xmd: dow ppc405_i/code/system.elf xmd: run xmd: profile % gprof ppc405_i/code/system.elf gmon.out -O3: profile doesn't work -O2: mmc problems? -O1: seems to work. And this is from memory: 1. I had to reserve memory at 0x1c00000 (the top of my sdram) to store profile data. 2. The PIT interrupt is initialized automatically by code inserted by xilinx profiling software. 3. I disabled my interrupt because the init code conflicted with xilinx profiling code. I probably could have re-enabled my interrupt, but I didn't need to. 4. My only code change was to disable my interrupt. Alan NishiokaArticle: 112888
"leevv" <leevv@mail.ru> schrieb im Newsbeitrag news:1164903515.526347.126760@l12g2000cwl.googlegroups.com... > > Antti wrote: >> leevv schrieb: >> >> > Hi Antti, >> > What ver of MPMC2 are you using? >> > They fix OPB related bug in the october release. >> > >> release 10202006 >> october 20th? >> >> BUG : PRESENT, OPB just doesnt work >> >> Antti > > We had the problem with 2 ppc trying to share opb bus through the > internal PLB to OPB bridge. > On the august mpmc2 release, PPCs just hang when had simultaneous > access to the same OPB peripheral. > > We used workaround with standard external PLB2OPB bridge. > THen we test new version (october) and found that this problem gone. > But we didn't switch our design to the new core and still using august > ver with workaround (don't want to introduce new bugs) > > I found that mpmc2 design team is more or less cooperative when you > report the bugs. > Lately they reguire to open webcase, but before I just sent them email > directly and they did respond quickly. > I wanted to have simplest system, eg the MPMC2 is configured with 1 port, OPB, and is used as main memory to MicroBlaze this is really simple config, and as per datasheet defenetly allowed config options. but - the OPB PIM just doesnt work, because of the FIFO bug... AnttiArticle: 112889
"A FPGA is nothing more than a prototyping platform" This an easily falsifiable statement. I've actually never knowlingly met anyone who has transferred an FPGA design to an ASIC. I'm not saying it doesn't happen a lot, just that there's obviously a whole community of FPGA users of whom you're not aware. Resources for those interested in reconfigurable supercomputing: Sign up to the openfpga mailing list: http://www.openfpga.org/ check out the presentations from RSSI from the past two years: http://www.ncsa.uiuc.edu/Conferences/RSSI/agenda.html http://www.ncsa.uiuc.edu/Conferences/RSSI/2005/presentations.html Come to Manchester in March: http://www.mc.manchester.ac.uk/services/courses/fpga/2007 Reconfigurable HPC, it's all about programming... The fabric is capable enough (though double-precision FPUs instead of 18x25 mults would be nice) Cheers, Robin On Nov 29, 8:25 pm, Ralf Hildebrandt <Ralf-Hildebra...@gmx.de> wrote: > tenteric schrieb: > > > I need to be more precise - my passion is just very fast computation - > > I'm very interesting in implementing any math algorithm thus it will > > work as fast as it can.A FPGA is nothing more than a prototyping platform. Anything you can > build as digital hardware you can map to an FPGA. You just don't need to > manufacture wafers with your chips, bond and house them. > > RalfArticle: 112890
Hello there.. Hope that someone would help me. I am using the the OPB_EMC ip to read and write from a flash memory. The problem is that if on the following code "XIo_Out16 (XPAR_OPB_FLASH_CNRTLR_MEM0_BASEADDR + address.long_word, data_word.word)" the variable data_word is 0x400000 or 0x700000 the software halts in that particular line. I got into this conclusion after running in debug mode GDB. As far as I understand the even if no flash memory is connected, under no cirumstences the opb_ems should halt the microblaze processor. Please note that the rest of the number doesn't matter (the problem occurs even if the Lsbs are different then '0') Has anyone encounter such a problem?? thanks and best regurds. BTW - the XPAR_OPB_FLASH_CNRTLR_MEM0_BASEADDR is 0x24000000 and the max addres is 0x25ffffff so the is no address conflict. Guy ZurArticle: 112891
Robin, I have to laugh. Yes, some designs do get migrated to ASICs. As a FPGA designer/supplier, and someone who talks to customers (I created the customer escalation procedures here 6 years ago), I got to hear all the bad experiences which customers have had in trying to create an ASIC from a working FPGA. Timing closure almost always causes a mask revision, and IO problems rate as the second highest cause of mask re-spins. It doesn't even matter whose FPGA they are trying to convert, or even if they are trying to go a "guaranteed" route: they all fail more often than not. [Advertisement: And now with EasyPath(tm), there is even less reason to torture yourself. Just freeze your design, and pay less.] But, there are those who realize that an ASIC will cost less (their volume turns out to be much larger than they ever anticipated), and for them, they will/must continue to do the conversions. They will continue to inform us that their business will "go away" as of a certain date, and we will continue to see them buying their significant quantities well after the date they gave us (indicating they are waiting for their mask revisions to actually work). AustinArticle: 112892
Robin Bruce schrieb: > "A FPGA is nothing more than a prototyping platform" > > This an easily falsifiable statement. I've actually never knowlingly > met anyone who has transferred an FPGA design to an ASIC. I'm not > saying it doesn't happen a lot, just that there's obviously a whole > community of FPGA users of whom you're not aware. Ok - I knew that this generalisation is like stepping into a nest of hornets, but it is one of the shortest answers you can give to describe what a FPGA is good for - especially if one does not know how much knowledge has the OP. RalfArticle: 112893
Thanks, the device family in V2Pro and the configuration is 1 lane, 4 byte, framing with version 8.2 of ISE. I hope this help. Rog. "Hemanth" <hpsham@gmail.com> wrote in message news:1164645316.119115.299830@j72g2000cwa.googlegroups.com... > Could you list which device family are you targeting, what was the > configuration ( # of lanes, 2/4 bytes, streaming/framing etc ) you > choose to generate the design and the ISE tool's version which is > throwing this error? With these details I might be able to answer your > question. > > > Roger wrote: >> When I try to Implement a design with an Aurora core (v2.4) in it I get >> the >> following error: >> >> ERROR:NgdBuild:753 - Line 68 in 'toplevel.ucf': Could not find >> instance(s) >> >> 'Inst_aurora_sample/aurora_module_i/lane_0_phase_align_i/phase_align_flops_r* >> ' in the design. To suppress this error specify the correct instance >> name or >> remove the constraint. >> >> The path to the FFs is correct. >> >> If I comment the following lines in "phase_align.vhd", it all seems to >> work >> OK: >> >> -- Attribute Declaration >> attribute KEEP_HIERARCHY : string; >> attribute KEEP_HIERARCHY of RTL: architecture is "true"; >> >> Does anyone know what's going on here please? >> >> TIA, >> >> Rog. >Article: 112894
send meyer-baese an email saying you bought his book... and ask him your question... you can find his email on the faculty page from the FSU college of engineering page: http://www.eng.fsu.edu/index_noright.php?page=faculty_staff_directory fl wrote: > Thank you very much. The problem is that I cannot get the claimed > performance of the example in that book. For the add_1p.vhd, 15-bit > (which said it could be 97.08 MHz in the book), I can only get 69.87 > MHz fmax. In this example, I don't modify the code at all. Even I add > the timing constraint, the result is the same. It is really bizarre. > For the post code, it was an exercise with the given results. I don't > know where it is wrong. Anyone could test the best performance of the > post code? > > > wallge wrote: > > fl, > > > > Meyer Baese was my teacher at FSU, and > > he taught my class using the DSP w/ FPGAs book he wrote. > > Its a small world... > > > > If you want to run an adder really fast you can instantiate an adder > > component > > from the altera mega function tool within the arithmetic components > > subsection. > > >From inside the megafunction wizard GUI you can select the level of > > pipelining > > within the adder. So you can select anywhere from 1 to N clock cycles > > of delay. > > The more delay, the faster you can clock the adder. > > > > As far as timing parameters, you can see all the timing (slack, etc) > > from one critical path to another > > within the timing subsection of the compilation report after you > > compile your design in quartus II. > > > > > > --geoff > > > > fl wrote: > > > Hi, > > > I am learning FPGA by a DSP book (1st edition) written by Uew > > > Meyer_Baese. There is an example about 16 bit adder with detailed > > > timing parameters, such as: tco=0.2 ns, tcgen=1.5ns tcico=0.3ns, > > > tsamerow=2.9ns, tLUT=1.9ns and tsu=2.7ns. The fmax of that 16 bit adder > > > is 74.6 MHz I think it is EPF10K20RC240-4 from the context. > > > > > > In my practice project, I can only see the IC(interconect) and CELL > > > delay timing parameters from the timing closure floorplan. Because the > > > fmax I get is lower (only 59.52 MHz from timing analyzer) than that in > > > the book, I want to know the difference. The purpose is I want to be > > > ensure whether I get the fast 16 bit adder. BTW, I post my code below. > > > Because the timing parameters give tco etc., I use register at the > > > input and output ports. > > > > > > Could you help me? Thanks in advance. > > > > > > > > > > > > LIBRARY lpm; > > > USE lpm.lpm_components.ALL; > > > > > > LIBRARY ieee; > > > USE ieee.std_logic_1164.ALL; > > > USE ieee.std_logic_arith.ALL; > > > > > > ENTITY add16 IS > > > GENERIC (WIDTH : INTEGER := 16; -- Total bit width > > > ONE : INTEGER := 1); -- 1 bit for carry reg. > > > PORT (x,y : IN STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > > > -- Inputs > > > sum : OUT STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > > > clk : IN STD_LOGIC); > > > END add16; > > > > > > ARCHITECTURE flex OF add16 IS > > > SIGNAL sum0, q2, q1 -- LSBs of inputs > > > : STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0); > > > BEGIN > > > reg_1: lpm_ff -- Save LSBs of x+y and carry > > > GENERIC MAP ( LPM_WIDTH => WIDTH ) > > > PORT MAP ( data => x, q => q1,clock => clk ); > > > reg_2: lpm_ff > > > GENERIC MAP ( LPM_WIDTH => WIDTH ) > > > PORT MAP ( data => y, q => q2, clock => clk ); > > > -------------- First stage of the adder ------------------ > > > add_1: lpm_add_sub -- Add LSBs of x and y > > > GENERIC MAP ( LPM_WIDTH => WIDTH, > > > LPM_REPRESENTATION => "UNSIGNED", > > > LPM_DIRECTION => "ADD") > > > PORT MAP ( dataa => q1, datab => q2, > > > result => sum0); > > > reg_3: lpm_ff > > > GENERIC MAP ( LPM_WIDTH => WIDTH ) > > > PORT MAP ( data => sum0, q => sum, clock => clk ); > > > > > > END flex;Article: 112895
tenteric wrote: > jez-sm...@hotmail.co.uk wrote: > >>tenteric schrieb: >> >> >>>Hello everybody. >>> >>>It seems, I wish to build my career as engineer who use FPGA to >>>construct ad hoc designs, in the field of fast computation. >>>I've heard about cryptoanalysts' FPGA experiments.. and I'm >>>interesting, where else I'll able to apply my professional profile, now >>>or in the near future? >> >>You can apply FPGAs to just about any field that you care to mention, >>there are plenty of companies who are activly seeking engineers with >>skills in designing with FPGAs.Personaly ive worked on and developed >>designs for telecoms systems,cryptographic systems,soft processor >>cores.AS you mention cryptograhic applications I wrote a pipelined AES >>core a couple of years ago and got my present job of the basis of the >>knowledge gained during the development of that core. > > > I need to be more precise - my passion is just very fast computation - > I'm very interesting in implementing any math algorithm thus it will > work as fast as it can. then you probably should also track this - a FPGA variant called a FPOA http://www.mathstar.com/index.html -jgArticle: 112896
Hello, and thanks for responding to my post. Quick question, did you have to pay for any IP to use the transceivers or is it free? thanks, joe Ben Twijnstra wrote: > Hi Joe, > > > Hello, I'm looking to do a design involving data rates near 4Gbps and > > was looking at using Altera's Stratix II GX transceivers to drive the > > data to a 4Gbps single-mode fiber-optic transceiver. I'm interested in > > how well the Stratix can perform this task, if anyone has some > > experience using the transceivers could you please let me know how well > > it worked for you? I've read the Altera's web site on the Stratix II GX > > and it sounds very promising, I just want to make sure that is does > > what it says it can. > > I've been toying around with Altera's own Signal Integrity board, and 6GBps > over 40" of trace plus 2ft of copper interconnect through SMAs works just > fine. 4GBPS over optic should be relatively easy. > > Feed the GX 100MHz of clock, put the PLLs into 40x, set the ALTGXB > transceiver interface to double-width mode (200MHz is workable in the core, > 400MHz is really, really stressing things), and as long as you properly do > your power decoupling and PCB layout you should have a working design. You > may need to tweak the pre-emphasis and/or equalization settings a bit to > get the best results, but so far the transceivers seem to be rock-solid. > > Best regards, > > > Ben > > > Best to contact your local (disti) FAE to provide you with the reference > schematic and board layout files of the SI board for reference.Article: 112897
Never mind. I figured it out... /MikhailArticle: 112898
Target = XC3S400 Spartan 3 Tool = ISE 8.2i If I understand correctly, the DCM does not use a PLL to multiply-up the input frequency; it's a DLL and it generates all required frequencies/phases by selecting outputs from a tapped delay line. I heard these taps are only tens of picoseconds apart. Is this so? Why then is the peak-to-peak jitter, as calculated by the DCM wizard, so large e.g. hundreds of ps? For Spartan 3 designs, the tools do not automatically take DCM jitter into account. To get it included, I've manually added INPUT_JITTER 0.82 to the end of my external clock constraint: TIMESPEC "TS_EXT_CLK" = PERIOD "EXT_CLK" 20 ns HIGH 50 % INPUT_JITTER 0.82; Half of this figure then appears as "clock uncertainty" on the timing analysis report, and PAR works that much harder to get closure. I don't like including DCM jitter this way. The input clock is clean. Is there a neater way to specify it on the DCM outputs where it belongs? TIA Andrew.Article: 112899
Andrew Holme schrieb: > Target = XC3S400 Spartan 3 > Tool = ISE 8.2i > > If I understand correctly, the DCM does not use a PLL to multiply-up the > input frequency; it's a DLL and it generates all required frequencies/phases > by selecting outputs from a tapped delay line. I heard these taps are only > tens of picoseconds apart. Is this so? Why then is the peak-to-peak > jitter, as calculated by the DCM wizard, so large e.g. hundreds of ps? > > For Spartan 3 designs, the tools do not automatically take DCM jitter into > account. To get it included, I've manually added INPUT_JITTER 0.82 to the > end of my external clock constraint: > > TIMESPEC "TS_EXT_CLK" = PERIOD "EXT_CLK" 20 ns HIGH 50 % INPUT_JITTER 0.82; > > Half of this figure then appears as "clock uncertainty" on the timing > analysis report, and PAR works that much harder to get closure. I don't > like including DCM jitter this way. The input clock is clean. Is there a > neater way to specify it on the DCM outputs where it belongs? > > TIA > Andrew. If its any help you can look at the source code for the unisim or simprim simulation model for the dcm in those respective library sources,I remember looking at them some time ago so it may help to get a better understanding.
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