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
marlboro, Yes, to meet PCI's strict setup time requirements (Tsu < 7ns for 33MHz PCI and Tsu < 3ns for 66MHz PCI.), AD and C/BE# should (must) be registered before calculating the parity of those inputs. Parity should be calculated from those FFs, and compare it against PAR all in one cycle. That way, the parity checker has 30ns (15ns for 66MHz PCI) for parity calculation + comparison against PAR versus 7ns (3ns for 66MHz PCI) for calculating the parity if inputs weren't registered (In the later case, comparison against PAR will be done in the next clock cycle.). Kevin Brace (If someone wants to respond to what I wrote, I prefer if you will do so within the newsgroup.) marlboro wrote: > > Hi, > You don't have to register the AD and C/BE for parity checker, that > can save you 1 clk, but beware of timing. How fast you want it gonna > be?Article: 54076
Praveen, Yes, you are on the right track that AD[31:0] and C/BE#[3:0] should (must) be registered before calculating the parity of it for parity checking purposes. However, you should be aware that when calculating the parity of it after the signals are registered, you should add "keep" or "preserve" attribute of the synthesis tool to constrain the final output coming out of the 36-input parity tree. What happens with most synthesis tools is that they almost always try to optimize the structure of the parity tree, and in that process, almost always mess up the original structure of the parity tree, often leading to timing problems with PAR input (PAR input is a PCI signal.). Kevin Brace (If someone wants to respond to what I wrote, I prefer if you will do so within the newsgroup.) praveen wrote: > > Hello Sirs/Friends, > I am designing a PCI core in which i have parity checker module. I > wanted to know how can design a parity checker which can meet the PCI > specification. I will have registered AD[31:0] and C/BE[3:0] signal > whose parity should be checked and PAR signal come in the next clock > and i have signal the PERR the next clock itself. How to design this. > Waiting for ur reply > PraveenArticle: 54077
I'm a student at the University of Oklahoma. We're using Xilinx Student Edition 4.2i for ECE 5623, Computer Hardware Design (feat. VHDL). Part of that class is a final project. Mine will be implementing parts of an MP3 decoder in hardware. The only way I have to test my hardware so far is to use the "testbench waveforms," which involves manually inputting the stream of data. I really would like to avoid this. Is there a way to feed a binary file into the simulator or testbench? If not, I'd like to whip up a quick little C (or Perl or PHP) program to generate a TBW file for me. Anyone got some pointers? Please reply back or e-mail. Mike Hollinger -- Michael C. Hollinger mhollinger@ou.edu Senior, Computer Engineering / Electrical Engineering Univ. of Oklahoma Boomer? Sooner!Article: 54078
Hello. I am new to programming CPLDs...and I would like to know from experienced programmers... what are the most popular applications for this? for consumers? Industry? Military? Return on investment of time? and resources?? any good authoritative textbooks on this??Article: 54079
Dear Friends, Earlier this year we commenced a project to port the open-source uClinux operating system (kernel version 2.4.x) to the Xilinx Microblaze softcore processor. The purpose of this message is to update you on the status of the project, and invite interested parties to join a new mailing list devoted to this effort. Status: ------- It is now possible to boot a basic uClinux kernel on one specific Microblaze target, which I have dubbed "mbvanilla". Clearly, the ability to target arbitrary microblaze hardware configurations is a major long-term goal of the project. I have submitted a series of patches to the uClinux source maintainers for inclusion in their CVS tree that will allow others access to the new code. When this is available I will notify the mailing list (see below). Work to be done: ---------------- The port is incomplete and experimental. There are several loose ends to be tied up before it can be considered "working", and even more before it will be anything approaching "stable". In the short term, the following issues remain outstanding: - elf2flt and bin_fmt_flat userland binary support - testing and completion of uClibc C library support - a root file system (romfs) - general kernel testing and debugging - proper integration into the uClinux kernel build system Longer term, we need to get a stable core of applications built and tested on the new platform, as well as networking support and much more. Further, there is a general desire to integrate or at least interoperate the kernel configuration process with the Xilinx platform generation tools. Hard real-time support and Microblaze/uClinux single-chip multiprocessing are also definitely on the agenda. Mailing list: ------------- While there is a dedicated and active uClinux mailing list (uclinux-dev@uclinux.org), I have taken the step of creating a microblaze/uclinux specific list. It is my intention for this list to operate for a maximum of six months, or until the port is stable enough that the participants can migrate to uclinux-dev. If it is appropriate, I will post a weekly digest of our new list across to uclinux-dev. To subscribe, send an email to majordomo@itee.uq.edu.au, with the following as the body of the message: subscribe microblaze-uclinux Follow the instructions in the reply email, then you will be on the list. I expect it will be quite low volume, but would love to be proven wrong! Finally, if you know of anybody else who might be interested to join this project, then please feel free to forward this message to them as you see fit. I have very high hopes for this work, and think that there lie ahead many exciting opportunities for uClinux on the Microblaze platform. Any involvement, no matter how small, will be welcomed and appreciated. Thank you, John Williams -- Dr John Williams, Research Fellow, Reconfigurable Computing, School of ITEE University of Queensland, Brisbane, Australia Ph : 61-7-3365-8305Article: 54080
praveenkumar1979@rediffmail.com (praveen) wrote in message news:<ff8a3afb.0304010305.7274cd95@posting.google.com>... > Hello Sirs/Friends, > I am designing a PCI core in which i have parity checker module. I > wanted to know how can design a parity checker which can meet the PCI > specification. I will have registered AD[31:0] and C/BE[3:0] signal > whose parity should be checked and PAR signal come in the next clock > and i have signal the PERR the next clock itself. How to design this. > Waiting for ur reply > Praveen For best results, your parity-module design should have two pipeline stages: one on the incoming data (before the parity logic) and one on the parity-out signal itself, after the parity logic (single FF). There are actually two separate parity operations on the PCI bus: * When your device drives the A/D lines, it must also drive the PAR line with the correct parity one clock later. You can drive the parity-logic input pipeline register with the same data that is used for the A/D-out register (you DO have a pipeline reg on the A/D-out path, don't you?); the registered parity-out signal will now be at the correct clock-cycle. * When you check parity on incoming address/data, you have two clocks to report parity errors on PERR#. Surprise! when the PCI spec was defined, they recognized the need for two pipeline stages! (note that most of the PCI spec is intended for pipelining - the only exceptions are the TRDY#/IRDY# signals; if you design a PCI interface, they are usually the hardest signals to get within the PCI timing spec). If you have the available logic resources, I'd recommend using two separate parity modules for incoming and outgoing data paths; this may even require less logic, since you save a lot of muxes. It will make the design easier to bring to timing spec.Article: 54081
Jonathan, Your comments are right on target. I considered using internal FPGA clocking (>5x microprocessor clock) to implement a state machine approach to the interface, but decided to go asynchronous on the input side of the registers and synchonous on the output side, where required. Most of my registers do things like provide one side of the data for equality comparators or set parameters that will be used after a reset command. As such there are no issues in terms of metastability or even the use of latches (which I'm not using, but...). In the case of the RAM lookup tables, all operations stop within the FPGA when they get loaded by the uP, so I have very few worries about getting into trouble there as well. Thanks, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Jonathan Bromley" <jonathan.bromley@doulos.co.uk> wrote in message news:b6bglu$jug$1$8300dec7@news.demon.co.uk... > "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message > news:Z2%ha.215$Iz6.14915853@newssvr14.news.prodigy.com... > > In order to maximize access speed I'm thinking of using both edges of the > > uP's WE pulse to run these SelecRAM ports. The idea is to capture the > data > > byte on the leading edge and use the trailing edge to increment the > address > > counter that is driving the SelectRAM block. With this, all the uP has to > > do is present new data and pulse WE until it fills the memory bank. > > I'm looking for feedback on this technique. Any problems? Any reason for > > not taking this approach? Any other approaches that might warrant > > consideration? > > I've used this kind of "autoincrement" mechanism successfully in the > past, but you must pay attention to the details. > > I'm guessing that your FPGA system clock is way faster than the > CPU I/O write cycles, so it's reasonable to run some kind of > state machine inside the FPGA, controlled by activity on WE. > That way you can schedule your memory writes and address updates > in whatever way is most appropriate. You could even do > address pre-increment (instead of post-increment) if you wanted. > > Look out for data setup and hold times relative to WE edges. Like > I said, it's all in the detail. Watch out, too, for the > comparatively long delays through FPGA I/Os - particularly if > you're relying on timing relative to the CPU clock, and you > generated that CPU clock inside the FPGA. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK > Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: http://www.doulos.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. > >Article: 54082
I find Excel incredibly valuable in various programming tasks, not just FPGA's. On that topic though, I've been wondering if anyone has published useful worksheets/utilities in order to facilitate the use of Excel in FPGA programming. I'm working with Verilog, however, more generalized solutions are of interest as well, hence the cross-post to comp.arch.fpga. I have, for example, created Excel worksheets to generate the Verilog code to initialize large RAM blocks with data. The desired data is entered or calculated on a column, a graph shows it to the right and the whole thing is reformatted into Verilog code that can be cut and pasted right into a module. Another example is a little VBA utility I wrote that lets me generate module instantiation code (or other variants) by taking a sample instantiation, say: widget U1 (.A(8'h23), .B(8'h99), .C(8'hAB)); replacing the parameters/instance name with "%n%": widget %1% (.A(%2%), .B(%3%), .C(%4%)); and then using rows and columns withing Excel to enter/calculate the parameters for multiple instances of this module. As in the prior example, the code can then be cut and pasted right into Excel. My thinking is along the lines of trying to limit repetitive error-prone typing and automating as much as possible. Another candiate is the repetitive signal, port type declaration style that requires typing the same thing three times. In Excel this can be done once and then transfered into your Verilog editor in one shot. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 54083
Hi Mike, Yes you can stream in data using sockets or pipes in Modelsim. For sockets you can use TCL on Modelsim PE/XE or TCL/C/C++ on Modelsim SE. If you program in Verilog you can use the PLI/VPI interface on Modelsim PE/XE. A nice demo of the project would be to read the encoded file from your harddisk and stream the decoded output realtime to your soundcard :-) Modelsim PE/SE (not XE) is most likely fast enough to handle this task. I have a real-time fractal generator on my website which generates 80KBytes of coordinates every second on a 2.4GHz P4 machine. Good luck, Hans. www.ht-lab.com "Mike Hollinger" <mhollinger@ou.edu> wrote in message news:50461b3.0304011921.20e295e0@posting.google.com... > I'm a student at the University of Oklahoma. We're using Xilinx > Student Edition 4.2i for ECE 5623, Computer Hardware Design (feat. > VHDL). Part of that class is a final project. Mine will be > implementing parts of an MP3 decoder in hardware. The only way I have > to test my hardware so far is to use the "testbench waveforms," which > involves manually inputting the stream of data. I really would like to > avoid this. > > Is there a way to feed a binary file into the simulator or testbench? > If not, I'd like to whip up a quick little C (or Perl or PHP) program > to generate a TBW file for me. Anyone got some pointers? > > Please reply back or e-mail. > > Mike Hollinger > -- > Michael C. Hollinger > mhollinger@ou.edu > Senior, Computer Engineering / Electrical Engineering > Univ. of Oklahoma > Boomer? Sooner!Article: 54084
I need to do 32bit fixed-point 6x6 matrix multiply in hardware - it's a design which needs much matrix operations and everything says that fixed-point will be enough. I plan to keep matrices in fixed locations in embedded ram, feed 'start' signal to multiply logic and look for a result after doing other things. It will be used with Nios. Are there any guidelines or examples on the web (I don't like reinventing the wheels :-) Or (at least) I'd like to see some comments, ideas, does and don'ts from you... As I will need matrix transpose from time to time, I will put simple mux between row/column counters and address generation logic. Any suggestions? Any ideas? BTW: It's not a homework :-) -- jerry "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." - Ernst Jan PluggeArticle: 54085
"Steve Casselman" <sc_nospam@vcc.com> wrote in message news:<MMria.308$Zg.28941436@newssvr15.news.prodigy.com>... > I wrote a little artical for EETimes that proposed having a full wafer of > FPGA fabric that included a purge map for defective resources. You could > have an area on the FPGA die that got laser burned to record the defects. > Once you have a "master" design rerouting around the defects would not be > that hard or take that long. Of course you know of the Xilinx program where > you give them a bitfile and they screen to that. But really someone will do > the work to include a bitmap someday. Like I say it would be great for wafer > sized FPGAs. Imagine a Billion gate device. You could put everything > including the OS on something that size. > > Steve > Now that takes us right back to WaferScale integration. At least one company out of U Cambridge did wafer scale integrated DRAMs in late 80s, self test would automagically find a serial path through all the good die and bypass over the dead ones. The wafer was never sawed. Ofcourse it died when Japan Inc figured how to make DRAMs >>64K. Wafer scale work became irrelavant about 15yrs ago. Still the self test of an FPGA and the rest of it would be an enormouse undertaking.Article: 54086
Ralph Mason <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote: : ... : Thanks for your help, it turns out that the CPLD wouldn't run in low power : mode, until I feed a WR line into a global clock pin. It should work anyhow, until very fast signals (> 20 MHz) were involved. Did you give a sensible constraints file? : There was a thread here a while back about feeding an input signal out a : global clock pin and then using the global clock signal - thus letting any : pin be a global clock. If you still have a GCLK pin unconnected, feed the signal to that output and read it back as GCLK signal. XST is normally good at doing this automatically. Read the log files. : Does anyone have any idea how to get the syntheses to understand that? As said above, XST will do it automativally, until you put up obstacles. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 54087
I want to config Altera sram based FPGA (ex ACEX series) with AVR MCU+EEPROM by ps mode, because the smallest AVR mcu only have 6 IOs,and clk need 1, so I think I may tie e2prom's clk whith fpga's DCLK,tie e2prom's Dout with fpga's data0, I wang to see if it alwayes config successfully when I low nConfig,I first feed some dummy bits before the valid config data,and then feed right data. sorry for my poor english.Article: 54088
"Martin Euredjian" <0_0_0_0_@pacbell.net> writes: > I find Excel incredibly valuable in various programming tasks, not just > FPGA's. On that topic though, I've been wondering if anyone has published > useful worksheets/utilities in order to facilitate the use of Excel in FPGA Many (most?) designers do this with their favorite tool like Perl, Python, Ruby, Guile, Dylan, etc. Personally I prefer Common Lisp. Writing small utilities in Emacs Lisp is also very productive since you don't have to import/export data from external tools. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petterArticle: 54089
Hi I'd like to know if is there any possibility to make usable IPCore from Xilinx FFT 256pt, for Spartan? Spartan IIe has similiar resources as virtex. Or could You give me advice where I can find core this class? Greatings Jerzy GburArticle: 54090
Hi There, I am currently working on a FPGA based System using a serial arbitration strategy. I want to implement a dominant "low", and a recessive "high", and for that I need to know if APEX 20k have the possibility to use pullups on certain signals. hope you can help me best regards Chris.Article: 54091
You didn't say how fast it has to run. Given enough clock cycles you
could do it with two adders, a memory with address counter and a
little bit of logic.
jerry1111 wrote:
> I need to do 32bit fixed-point 6x6 matrix multiply
> in hardware - it's a design which needs much matrix
> operations and everything says that fixed-point will be
> enough. I plan to keep matrices in fixed locations in
> embedded ram, feed 'start' signal to multiply logic and
> look for a result after doing other things.
> It will be used with Nios.
>
> Are there any guidelines or examples on the web (I don't like
> reinventing the wheels :-) Or (at least) I'd like to
> see some comments, ideas, does and don'ts from you...
>
> As I will need matrix transpose from time to time, I will
> put simple mux between row/column counters and address generation
> logic.
>
> Any suggestions? Any ideas?
>
> BTW: It's not a homework :-)
>
> --
> jerry
>
> "The day Microsoft makes something that doesn't suck is probably
> the day they start making vacuum cleaners." - Ernst Jan Plugge
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 54092
It is possible. What are your performance and wordsize requirements?
We've got a 16 point core for this family, it would have to be married
with a phase rotator (which we also have) to get 256 points in two
passes. The rotator and core together will fit in an XC2s300e. We've
also got a radix4 core that would fit and would require 4 passes.
That one will fit in a smaller device, and in fact by using the
multipliers will fit in an XC2V40.
Jerzy wrote:
> Hi
> I'd like to know if is there any possibility to make usable IPCore
> from Xilinx FFT 256pt, for Spartan?
> Spartan IIe has similiar resources as virtex.
> Or could You give me advice where I can find core this class?
>
> Greatings
>
> Jerzy Gbur
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 54093
Hi all,
I am using a SpartanII FPGA (XC2S100-5tq144) and I use the Xilinx
Multilinx Cable to configure it (Boundary-Scan Mode). Every time the FPGA is
configured and after 1-2 minutes of operation, it seems to "lose" its
configuration, stops to operate normally and the MultiLinx 's power
indicator turns off, although the power supplies continue to operate
normally. The same problem exists when the MultiLinx is detached from the
board after the configuration.
Does anybody have similar experience?
Thank you in advance,
Stamatis
Article: 54094
I'm currently using QuartusII (2.2sp1) under Linux. I prefer not to
use the GUI except for floorplanning. Hence I prefer the quartus_cmd
tool.
Is there a smart way to wait for the completion of the "cmp start"
command without doing an idle loop? Since I'm not running the GUI I
don't need to do any refresh.
I would like to do something like:
puts $gOut "compilation started at [clock format [clock seconds] -format {%D %T}]"
set status [cmp start -blockuntilcompleted]
if {$status == 1} {
puts $gOut "compilation completed at [clock format [clock seconds] -format {%D %T}]"
} else {
puts $gOut "compilation failed: $status"
}
Unfortunately, cmp start does not have a -blockuntilcompleted option.
Currently I'm wasting valuable CPU time in a tight loop within
quartus_cmd waiting for [cmp is_running] to become false.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
Article: 54095> You didn't say how fast it has to run. Sorry - I was so absorbed with this problem that I forgot to write it: 10us with 40MHz clock => 400 cycles would be perfect, but it's almost impossible - at least from my current point of view. I'll be happy getting any reasonable speed of course, but this timing gives an idea how should it be.... I have to do 6 muls and cumulate them (6 adds) for each element from result matrix. Matrix is 6x6, so 36 elements gives 216 muls and 216 adds.... Now I'm thinking about some sort of parralel operations, but it's not so simple because of storing data in ram. The best would be to store each row from A in separate block, columns from B in another 6 blocks, multiplying with 6 parallel logic pieces and feed results to FIFO. Each row/column is 6x36 bits - - maybe it would be better to make some pipelinig... Now I have 10 sheets of paper with various solutions, but I'd like to hear opinions from 'another point of view'.... Selected device is EP1C6 from Altera. PS: Sorry for my bad english, but I'm more reading than writing. -- jerry "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." - Ernst Jan PluggeArticle: 54096
> > > + There is a way to configure your FPGA with PCI9080/54/54 signals > > > witout PROM and additional PLDs. Think a little and you would find it > > > yourself. I'm not going to tell you how :) > > > > ummm, use an ISP CPLD? > > > > Nah. No CPLD. Just PCI9056, FPGA and one pullup resistor... > > > Seriously, tho', I guess you would use the FPGA's parallel config > > mode. > > > > No, I don't. Everything works with Passive Serial (speaking in > A-terms). Well, there is a user output pin...though perhaps DEVSEL could be pressed into service. Actually there's any number of outputs that could conceivably be wiggled.Article: 54097
Hello, I am using Simulink to model a divider. My input is two integers of size 31 bits for the numerator and 24 bits for the denominator. For the precision I require, the result requires 43 bits consisting of 37 fractional bits and 6 bits for the magnitude. I see that Xilinx has a pipelined divider core (v2.0), but will this give me the resolution I need? If not, does anyone know of any other cores that I can use for a Xilinx Virtex II part? SalmanArticle: 54098
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:xhwia.425$P41.30953712@newssvr14.news.prodigy.com... > Your comments are right on target. I considered using internal FPGA > clocking (>5x microprocessor clock) to implement a state machine approach to > the interface, but decided to go asynchronous on the input side of the > registers and synchonous on the output side, where required. Most of my > registers do things like provide one side of the data for equality > comparators or set parameters that will be used after a reset command. As > such there are no issues in terms of metastability or even the use of > latches (which I'm not using, but...). OK, but beware that if you use decoded WE directly to clock data into some registers, the FPGA tools will probably try to put it on to a dedicated clock net, and if you have very large numbers of these signals then there could be trouble with allocation of the clock net resources. Any special reason for choosing the async write? I know it's conceptually easier, but I've always found it was less pain in the long run to stay synchronous where possible (and you clearly *can* stay synchronous in this case). -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 54099
"Michael S" <already5chosen@yahoo.com> ha scritto nel messaggio news:f881b862.0304011447.2808066f@posting.google.com... > According to TI, the fastest C67 (TMS320C6713-225) has a > _peak_ > performance of 1350 MFLOPs: (4 FADD + 2 FMUL) * 225MHz. > Sorry for nit picking, I couldn't resist. Ok, you are right too. It's the 62x family that has over 2000 MIPS, but they are MIPS, not MFLOPS. :) -- Lorenzo
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