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
The documentation for the lwIP core (v2.00a) shows that there's only support for FIFO data transfers when using the TEMAC core. Will there be support in the future for DMA/SG? I'm still using EDK 8.2 sp2, and if 9.1 has support for it, I will consider upgrading. Thanks, -- KunalArticle: 117851
If you use CoreGen to generate these FIFOs, you can give it read/write frequencies. CoreGen creates RPMs (relationaly placed macros) so the design coregen gives you should meet timing, because the placement has already been done and the placement tool shouldn't touch it... That being said.... there are numerous reasons why coregen isn't helpful.. as far as i've found, the primary reason is if you need a fifo that's bigger than 18k. When they added the work around for this hardware flaw (fifo generator 3.2 i think?) they seem to have disabled the ability to use cascaded FIFOs. So if you want to do this, you need to instantiate primitives (unless you're willing to take the resource and performance hit of just casading coregen blocks and implementing many more resource hungry "patches" than you really need) , implement the work around by hand, and constrain your half-period paths appropriately.... yeaup... pretty much a pain in the rear either way.... between this patch and the fact that there's no true "1 word left" almost empty flag (or almost full flag), I think Xilinx royally messed up on the FIFO16 block.... Just using straight block ram FIFOs takes just a few more resources than the patch (especially if you're using independent read/write clocks - that patch is HUGE) AND gives you all the normal FIFO flags.... On Apr 10, 6:33=C2=A0am, "GaLaKtIkUs=E2=84=A2" <taileb.me...@gmail.com> wro= te: > Hi everybody, > In the new version (2.1) of the Virtex-4 User Guide (ug070), in the > FIFO chapter is described the synchronous clock work-around (page 161) > to solve the FIFO bug. At the end of the paragraph the following is > written: "The connections between the input registers and the FIFO16 > must be tightly constrained, as this part of the circuit effectively > runs at =C2=A0twice the clock rate." > Can anybody explain me which contraints are needed? placement? timing? > an example is wellcome! > > Thanks > MehdiArticle: 117852
motty, No offense taken. I have the case number, and I will follow up with you off-newsgroup. I understand your frustration, and it is something we are aware of. Even if these folks were here on the west coast of the USA, they would then be "out of zone" for India, China, Japan, Europe, and England. The solution to this must be something that works for everyone. AustinArticle: 117853
On Apr 11, 3:16 pm, "Symon" <symon_bre...@hotmail.com> wrote: > "Anne" <anneatkin...@yahoo.com> wrote in message > > news:1176313795.460803.304700@q75g2000hsh.googlegroups.com...> Does anyone know of a good point of contact at Element CXI? > > Ah, "point of contact". That makes more sense. I thought for a moment you > meant POC as in the Neil Young song... :-) Interesting website... Lots of vaporware from the looks of it. Good use of buzzwords. Probably a very small outfit if you're having trouble finding a contact.Article: 117854
Evnin' Just received the ispLever Linux DVD today... Install went fine...but when setting up environment or trying to start: me@home ~ $ setup_lv.sh Creating local directory ~/.isplever_lin/ sed: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Setup complete for ispLEVER 6.1 me@home ~ $ ispgui sed: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory projnav: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory rm: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Any idea why ispLever messes up the environment? And yes...libc.so.6 is under /lib (o; thx rickArticle: 117855
On Apr 11, 1:24 pm, "wallge" <wal...@gmail.com> wrote: > Just wondered if anyone here has used these devices... > I want to do embedded computer vision applications > and it sounds like they are a pretty good fit. > But I have no idea about the difficulty of using the tools > and getting algorithmic concepts into hardware... > > any feedback would be great. We've had some experience with these, but to date most of the work has been done by "software guys" who have had some trouble getting the hang of the programming paradigm. I think if your background is in FPGA and other hardware design you'll have an easier time of it. I like to think of the FPOA as an FPGA without the main fabric, only DSP and memory blocks. This is a bit of simplification since the ALU's in the FPOA are really little programmed sequencers, but it gets across the granularity of the part. Don't expect to write some very high level code that is magically mapped into a quantity of these blocks as for example your VHDL or Verilog might fit into Slices in Xilinx FPGA's. In that respect the tools are relatively primitive, more like FPGA editor than anything else I can think of. That being said, if you can partition your algorithm into pieces that fit the blocks of the array, this part is much easier to meet timing with than FPGA's. The headaches come in the interconnect where you are forced to add pipeline delays based on route length. There is some support in the tools to help deal with this, but again it isn't as "pushbutton" as we've become accustomed to with FPGA tools. Other issues arise when your data flow is constrained by peripherals that require data to enter or exit the part on particular columns or rows, and by the use of MAC and register file blocks that are more sparse throught he array than the ALU's. The design entry runs under Visual Elite, which has some nice features and simple built-in simulation. However the top level of your design is pretty much a schematic calling up the block elements of the array. If you can give an example of the kind of algorithms you might do in the part I might be able to let you know what to expect for "level of pain" to get it into the FPOA. Regards, GaborArticle: 117856
Hi Thomas yes that's what i did in simulation to get the expected signal, but the problem is that my signal is changing whith the clock edge so what i ll do is to use a digital analyzer to send the signal to the fpga and i ll check the FPGA behavior, thank you, A.Article: 117857
Now a little further: me@home ~ $ ispgui projnav: symbol lookup error: /home/klingler/.isplever_lin2/ispcpld/mw/lib-linux_optimized/libshlwapi.so: undefined symbol: Mw___uuid_DependancyNode Although the ispgui csh script sets the path where libuuid.so is located... cheers rick On 2007-04-11 23:50:32 +0200, Jedi Router said: > Evnin' > > Just received the ispLever Linux DVD today... > > Install went fine...but when setting up environment or trying to start: > > me@home ~ $ setup_lv.sh > Creating local directory ~/.isplever_lin/ > sed: error while loading shared libraries: libc.so.6: cannot open > shared object file: No such file or directory > Setup complete for ispLEVER 6.1 > > > me@home ~ $ ispgui > sed: error while loading shared libraries: libc.so.6: cannot open > shared object file: No such file or directory > projnav: error while loading shared libraries: libpthread.so.0: cannot > open shared object file: No such file or directory > rm: error while loading shared libraries: libc.so.6: cannot open shared > object file: No such file or directory > > > Any idea why ispLever messes up the environment? > And yes...libc.so.6 is under /lib (o; > > > thx > rickArticle: 117858
H=2E Peter Anvin wrote: > Hi all, > > I have a potential (hobby) project, where I'm looking at needing, in > effect, a CPLD and a =B5C that can share memory. +5 V I/O tolerance is > necessary (for about 52 signals coming into the board), and I would like > to keep the power supply complexity to a minimum since I'm really a > software guy and don't particularly trust my board layout skills. > > Anyway, I was looking at using an Atmel FPSLIC part, but it looks like > the tools are prohibitively expensive. I was wondering if anyone knows > of a similar part that would be less expensive once the tools are > accounted for? The alternatives seem to be using a Cyclone or Spartan > big enough to integrate the whole design including =B5C, but they require > complex power supplies and external voltage converters, or cobble > something together from multiple parts. You need to define just how much the CPLD portion needs to DO. - ie how many macrocells are needed How much memory is shared, and what bandwdith is needed ? It is quite easy to set up shared memory access on a Microcontroller, with external RAM and a CPLD - choose a fast SRAM, and lock the CPLD access to the idle periods in the uC bus - that way, you emulate dual-port memory with cheap SRAM. If the uC memory bandwidth are lower than the CPLD-memory, you could consider a SPI port into the CPLD, as that simplifies the PCB layout and opens more uC options. -jgArticle: 117859
axr0284 wrote: > Hi, > I am trying to measure an input signal that will be a square wave of > a certain unknown frequency in the range 1MHz to 4 MHz using an FPGA. > I have no control over that input signal. The FPGA should be able to > track the signal as it changes. Usually there is a +-5% max shift in > frequency from time to time. There is no reference clock for this > signal. > > I am not sure a simple counter will be an effective solution in this > case. I am afraid of setup time issues since the internal FPGA clock > will not be synchronized with the external signal. Can one phase lock > two signals easily in an FPGA? I would probably need a counter > running at 400 MHz to effectively to measure a 1% change in a 4MHz > signal accurately. > > I am wondering if there is an asynchronous solution to this issue that > might be more effective. Any ideas would be highly appreciated. Thanks > a lot, You forgot to mention how often you need this information updated ?. If you need to know on every single cycle, then yes, you need 2.5ns precision (which does not have to 400MHz, it can be 100MHz with 4 phases) If you do not need the info on every cycle, but just want to track slower changes in speed, then the task becomes simpler - a 7bit frequency counter will resolve to < 1%, or you can create a hybrid- eg if you measure over 10 cycles, a 40Mhz clock will give 1% resolve at 400KHz measurement bandwidth. -jg .Article: 117860
"H. Peter Anvin" <hpa@zytor.com> wrote in message news:1cKdnUK2McvPnIHbnZ2dnUVZ_sOknZ2d@comcast.com... > Hi all, > > I have a potential (hobby) project, where I'm looking at needing, in > effect, a CPLD and a µC that can share memory. +5 V I/O tolerance is > necessary (for about 52 signals coming into the board), and I would like > to keep the power supply complexity to a minimum since I'm really a > software guy and don't particularly trust my board layout skills. > > Anyway, I was looking at using an Atmel FPSLIC part, but it looks like the > tools are prohibitively expensive. I was wondering if anyone knows of a > similar part that would be less expensive once the tools are accounted > for? The alternatives seem to be using a Cyclone or Spartan big enough to > integrate the whole design including µC, but they require complex power > supplies and external voltage converters, or cobble something together > from multiple parts. > http://www.enterpoint.co.uk/component_replacements/craignell.html Cheers, Syms R. Brewer.Article: 117861
I keep on getting Setup time violations from ModelSim despite the fact that my design successfully placed and routed within the given time constraint. Can anybody suggest a reason for that or a work around? I assume that I do not need to constraint the specific paths causing the violation since the clock period constraint should be global for all paths. Thank you.Article: 117862
In theory, XST claims to support the Verilog $readmemh to initialize memory. I'm using the latest 9.x s/w verion. I look at the .syr output file from XST, and it claims to have read the file. But... If I hook a logic analyzer up to the output of the memory, it looks like it never got initialized. Another problem I'm seeing is that XST appears to not like having an address line (@000) in the file. Also, if the the file is too short, XST complains and discards the initialization. I'll dig into this some more, but I was wondering if anyone had had any success with this. Thanks! John ProvidenzaArticle: 117863
Symon wrote:
> "Anne" <anneatkinson@yahoo.com> wrote in message
> news:1176313795.460803.304700@q75g2000hsh.googlegroups.com...
>> Does anyone know of a good point of contact at Element CXI?
>>
> Ah, "point of contact". That makes more sense. I thought for a moment you
> meant POC as in the Neil Young song... :-)
Maybe old Neil had it right :)
Nothing in Google other than
a December blog of the same December website.
http://pldworld.blogspot.com/2006/12/element-cxi-inc.html
-- Mike Treseler
Article: 117864
M. Hamed wrote:
> I keep on getting Setup time violations from ModelSim despite the fact
> that my design successfully placed and routed within the given time
> constraint. Can anybody suggest a reason for that
If that place + route met static timing,
I would expect that the design is OK.
-- Mike Treseler
Article: 117865Hi, I want to buy two books on CORDIC. One is focused on CORDIC theory and algorithms, another on CORDIC applications. Which is the best book about CORDIC algorithms? Which is the best book about CORDIC applications? Thank you. WengArticle: 117866
hi all,
iam doing projevt on Digital down converter.In that i need to multiply
RF signal and LO signal . which type of multiplier is suited for
multiplication of two sinusoidal signal using FPGA.if any body is
having code iwould be thankful to you
pls reply
kanthi
Article: 117867On Apr 10, 9:07 am, Richard Pennington <r...@pennware.com> wrote: > fpgabuilder wrote: > > Actually SystemC is open-source and I may just be able to do > > everything that you are doing in SMIL with a C++ library. The > > interfaces would plug straight into your code that is running on > > individual SBCs. Synthesis maybe a problem. I'd be curious to know > > things that you are able to do with SMIL that you cannot do with > > SystemC. > > >http://www.systemc.org/web/sitedocs/library_overview.html > > > Best, > > -sanjay > > I think I didn't describe what I'm trying to do very well. The way I see > it, SMIL would be used along with something like SystemC. > > I really wanted SMIL to describe interactions between systems. The > functionality of the systems would be created using currently existing > tools with SystemC being an example of one. > > SMIL is less of a language and more of a tool that allows you to > describe interactions. SMIL then generates a communication library based > on your description. SMIL currently uses TCP/IP as the communication > medium, but eventually I'd like to support other communication paths > such as CAN, serial ports, etc. > > What I'm really trying to do is define a way to send messages (SMIL > events) between these heterogeneous systems as simply and cleanly as > possible. When I talk about VHDL generation, I mean I'd like to generate > VHDL glue that would all events to pass directly to FPGA hardware. > > For example: Let's say a system consists of a Linux box and an Altera > FPGA running a NiosII and eCos (I use this example because it's sitting > on my desk ;-) > > Today, SMIL can generate code for both the Linux box and the Nios system > and these two systems can communicate with each other. Nothing fancy > here, but SMIL also generates code to do event timing, tracing, etc. > which helps me look at performance bottlenecks, etc. > > SMIL also can generate code to create threads of execution. In one > example I'm working on I have 16 threads of execution and event > interactions defined between them. Some are running on the Linux box and > some are running on the Nios. > > The SMIL code for that is about 600 lines. The bulk of the "application" > code would be written in C or C++. > > Where it gets more interesting for me is I'd like to generate enough > VHDL to allow the Linux box to send events to the FPGA (probably through > the Nios) and visa versa. Again, the main "application" code for the > FPGA would be SystemC, VHDL, etc. and written outside of SMIL. SMIL > would just describe and implement the interfaces, tracing, etc. > > I'm not trying to reinvent any wheels. I'm just trying to address a > problem that I've seen and found interesting. > > -RichArticle: 117868
On Apr 10, 9:07 am, Richard Pennington <r...@pennware.com> wrote: > fpgabuilder wrote: > > Actually SystemC is open-source and I may just be able to do > > everything that you are doing in SMIL with a C++ library. The > > interfaces would plug straight into your code that is running on > > individual SBCs. Synthesis maybe a problem. I'd be curious to know > > things that you are able to do with SMIL that you cannot do with > > SystemC. > > >http://www.systemc.org/web/sitedocs/library_overview.html > > > Best, > > -sanjay > > I think I didn't describe what I'm trying to do very well. The way I see > it, SMIL would be used along with something like SystemC. > > I really wanted SMIL to describe interactions between systems. The > functionality of the systems would be created using currently existing > tools with SystemC being an example of one. > > SMIL is less of a language and more of a tool that allows you to > describe interactions. SMIL then generates a communication library based > on your description. SMIL currently uses TCP/IP as the communication > medium, but eventually I'd like to support other communication paths > such as CAN, serial ports, etc. > > What I'm really trying to do is define a way to send messages (SMIL > events) between these heterogeneous systems as simply and cleanly as > possible. When I talk about VHDL generation, I mean I'd like to generate > VHDL glue that would all events to pass directly to FPGA hardware. > > For example: Let's say a system consists of a Linux box and an Altera > FPGA running a NiosII and eCos (I use this example because it's sitting > on my desk ;-) > > Today, SMIL can generate code for both the Linux box and the Nios system > and these two systems can communicate with each other. Nothing fancy > here, but SMIL also generates code to do event timing, tracing, etc. > which helps me look at performance bottlenecks, etc. > > SMIL also can generate code to create threads of execution. In one > example I'm working on I have 16 threads of execution and event > interactions defined between them. Some are running on the Linux box and > some are running on the Nios. > > The SMIL code for that is about 600 lines. The bulk of the "application" > code would be written in C or C++. > > Where it gets more interesting for me is I'd like to generate enough > VHDL to allow the Linux box to send events to the FPGA (probably through > the Nios) and visa versa. Again, the main "application" code for the > FPGA would be SystemC, VHDL, etc. and written outside of SMIL. SMIL > would just describe and implement the interfaces, tracing, etc. > > I'm not trying to reinvent any wheels. I'm just trying to address a > problem that I've seen and found interesting. > > -Rich It does make sense now and I guess there maybe a value in it as you have created it from need. Did you look at ImpulseC? It is based on work by Dr. Maya Gokhale and others in the field of streams based processing. http://www.impulsec.com/C_to_fpga.htm -sanjayArticle: 117869
On 2007-04-12, M. Hamed <mhs000@gmail.com> wrote:
> I keep on getting Setup time violations from ModelSim despite the fact
> that my design successfully placed and routed within the given time
> constraint. Can anybody suggest a reason for that or a work around? I
> assume that I do not need to constraint the specific paths causing the
> violation since the clock period constraint should be global for all
> paths.
It isn't clear in your post but I guess you are doing a post place and
route simulation. A typical mistake is to instantiate a post place
and route netlist from a testbench which was never intended to be connected
to such a netlist. An example:
mynetlist dut(.clk(clk),.signalA(signalA), ... );
always @(posedge clk) signalA <= someothersignal;
In this case signalA will probably not meet the timing requirements of
the flip flops inside the netlist.
/Andreas
Article: 117870Hi, The actual fsl PUT or GET instruction takes 2 clock cycles in MicroBlaze v4 and 1 clock cycle in MicroBlaze v5. Where is your code and data located? The macro you are using are also reading/writing the data that you want to use for the FSL link. Just disassemble the .elf file and look how the macro is implemented. Göran "eejw" <wilder_joel@hotmail.com> wrote in message news:1176311081.128421.36190@y5g2000hsa.googlegroups.com... > Just a couple more data points to add regarding performance of FSL... > > I created a 2-processor microblaze design connected by FSL links. > > With a simple program and using these functions: > > microblaze_bwrite_datafsl(data[index],0); > microblaze_bread_datafsl(result, 0); > > from mb_interface.h to pass data from one processor to the other and > back, and using the counter to measure performance, I found: > > 1. takes 9 cc's to write a data sample to FSL (doesn't matter if it's > 1 or 99 samples and dividing count result by 99) > 2. takes 10 cc's to read a data sample from FSL > > I tried the "non-blocking" functions as well and found the same > results. > >Article: 117871
> This is not strange: block-RAMs have 36bits-wide ports at most. Since you
> have some very small x64 memories that were previously forced into BRAMs,
> they ended up costing two BRAMs each. With three 8x64 and six 16x64 RAMs,
> this is 18 BRAMs recovered right there.
>
Ok that's cool. I guess this is indeed an invaluable point to take in the
future for efficient usage of my chip next time.
>
> Distributed RAM is slow unless you give it many output register stages to
> redistribute: each LUT can provide 16bits and these are patched together
> with muxes to provide larger memories. Your address signals will also have
> huge fanout which further contributes to the slowness. Since your 1920x12
> distributed RAM probably only absorbed one register, the very long paths
> you are seeing is from address bits down to some part of the way through
> the output muxes down to the absorbed FFs and then from those FFs through
> the remaining address muxes to the destination FFs.
>
Yeh it indeed had high fan out, hundred over!
>
> Do not bother with increasing PAR effort, this will do you no good. You
> need to either put that 1920x12 RAM in BRAMs or add register stages that
> synthesis will redistribute within the distributed memory to improve your
> timing score. Start by adding two register levels to your 1920x12
> distributed memory's output and your score will most likely drop from over
> 5M to possibly under 200k. Add extra registers until your timings are met
> or improvements stall. After this, you will need to realign your
processing
> pipeline to account for the delays on this large distributed memory.
>
Yah I put that in BRAMs and use aother instance (vertical sequential table)
for distributed ram.
Hmm, so I can add register levels? How do I go about that?
I tried selecting the register duplication both in the synthesis and
implement design options. But to no avail.
So do u mean using FPGA editor?
Talking about FPGA editor, I was wondering about moving the problematic
source CLBs closer to the destination so as to cut down the delay? But there
are quite a few implications due to the other wires connection to those
CLBs.
> BTW, what was your LUT and slice-FF usage with that last attempt?
Ah forgot to save...
Well I did another one with instances of the Vertical sequential table and
the horizontal and vertical cofficients table using distributed ram
(Before this change, I remembered the block ram usage was 33 out of 36 for
linebuffer instance using distributed ram and th 4 input LUTs was 84%)
Number of Slices: 6718 out of 14752 45%
Number of Slice Flip Flops: 9007 out of 29504 30%
Number of 4 input LUTs: 13229 out of 29504 44%
Number used as logic: 7010
Number used as Shift registers: 459
Number used as RAMs: 5760
Number of IOs: 322
Number of bonded IOBs: 316 out of 376 84%
Number of BRAMs: 36 out of 36 100%
Number of MULT18X18SIOs: 36 out of 36 100%
Number of GCLKs: 1 out of 24 4%
I figured this is vertical sequential table would be the better choice to
tackle the problem after forcing it to use distributed ram.
Article: 117872
Hi Dmitriy,
"Dima" <Dmitriy.Bekker@gmail.com> wrote in message
news:1176315833.175479.249970@y5g2000hsa.googlegroups.com...
> Certainly. These are the failing paths from the timing report:
Well, those are the failing timespecs, certainly! More useful would be the
paths themselves, from the TRACE report (.twr file), telling you the source
and destination nets of the worst N paths in each timing group (where N is
by default 3, I think). The clock uncertainty and skew are also reported
there.
Looking again at your clocking architecture, I'm not sure that the DCM
configuration you're using will guarantee a rising-edge alignment between
the 266MHz and 133MHz clocks - which is a requirement for the apu_fpu core.
> The cascading DCMs are mainly for DDR2 clock and its clk_90
> counterpart. This is the way they come out of BSB wizard. But path 3
> does fail from the start (DDR2 clock). It comes out failing from the
> BSB wizard without me changing anything in the design.
I haven't used the DDR2 core in the latest release but I understand you've
been advised that this warning can be safely ignored? Doesn't sound ideal
though. :-\
> (3) I am using the latest apu-fpu core (v3.0)
Excellent, thanks. The reason I wanted to check was that required clocking
configuration changed considerably (as you might or might not have noticed)
between v2.1 and v3.0 of the FPU core.
> I found it odd that even without the apu-fpu core, my CPU net fails
> when I try to clock it at 266 MHz instead of 300 MHz. All I did there
> was change the CLKFX multiplier and divider values (and uncheck
> CPMC405SYNCBYPASS)! Is there something I am missing here?
Yes, that's weird. I was about to ask what other logic you had running off
proc_clk_s, but...
> I am also using the MGT protector core, which runs off proc_clk_s.
> Would that impact the timing? I will try without it.
Good idea. Otherwise, the only things that are running off proc_clk_s are
(a) the FCB bus interface, which is mostly just wires, and (b) the CPU
itself, which just has minimum clock pulse widths (1.818ns in the
configuration you're using, I believe).
Hope you get to the bottom of this soon...
Cheers,
-Ben-
Article: 117873<kanthi.siddela@gmail.com> wrote in message news:1176354667.374826.51840@n59g2000hsh.googlegroups.com... > hi all, > > iam doing projevt on Digital down converter.In that i need to multiply > RF signal and LO signal . which type of multiplier is suited for > multiplication of two sinusoidal signal using FPGA.if any body is > having code iwould be thankful to you > > pls reply > > kanthi > The * operator is what you need. Google will help you to find an example of a signed multiplier, e.g. http://www.altera.com/support/examples/vhdl/vhd-signed-multiplier.html AlanArticle: 117874
fpgabuilder wrote: [snip] > It does make sense now and I guess there maybe a value in it as you > have created it from need. Did you look at ImpulseC? It is based on > work by Dr. Maya Gokhale and others in the field of streams based > processing. > > http://www.impulsec.com/C_to_fpga.htm > > -sanjay > Thanks for the link. I'll look into it. -Rich
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