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
If you want to make your logic "quiet" I would suggest using a set/reset or clock enable as the simplest way. This isn't going to solve issues after locking. I might have missed it in the thread but is your Vccaux connected in any way to a Vcco rail ? If it isn't please ignore the following: Statement - 2 designs that are similar at HDL level may be very different designs after synthesis. mapping and p&r. In terms of I/O power noise if you have not used I/O registers for all I/O in the design then significant differences in power noise may be experienced between 2 functional similar designs but never the less different. One line of HDL code can in some circumstances make a large difference in actual implementation. With non-I/O registers the effective output timing varies widely between I/O. The main consequence of this is switching of outputs is spread over a window of time rather than be close together. Using non-I/O registers you can get a different I/O timing spread, and hence noise, every time you make a minor alteration or difference. The good thing about spreading the switching of I/Os is that ground bounce and other power noise effects is usually less than a design that fully uses I/O registers. Ok so rather than bore everyone any more I suggest that if your Vccaux is connected to a Vcco you try and reduce noise in that Vcco. One way to do this is to reduce the drive on I/Os and add slew rate control. A more extreme method is to move I/O timing by using either both edges of the clock switching half the outputs on one edge the other half on the other edge. This technique can be further extended using multiples of the clock with clock enable or even phases from a DCM. Other techniques involve locking registers in particular places of the fabric to induce different timing between I/O. The latter is very much a last resort as timing can vary widely between batches, temperature, voltage etc. More simply you can also add more decoupling and separate your Vccaux from any Vcco power rails. Not always easy in already designed and built product. John Adair Enterpoint Ltd. - Home of Broaddown2 http://www.enterpoint.co.uk This message is the personal opinion of the sender and not that necessarily that of Enterpoint Ltd.. Readers should make their own evaluation of the facts. No responsibility for error or inaccuracy is accepted. "Sean Durkin" <smd@despammed.com> wrote in message news:2h9hnfFa6a0hU1@uni-berlin.de... > Austin Lesea schrieb: > > > John, > > > > Couldn't have said it better. > > > > Also, I would start a webcase with the hotline. > OK, I'll do that. But, as I said earlier, the thing that puzzles me, is > that input clocks, output pins etc. are all identical in both designs. > The only difference is in design B there is some more logic added, the > rest is the same. Obviously that affects the locking/not locking of the > DCMs... I've experienced something similar before, when I added a > Chipscope-Core to the design, and as long as that was connected the DCMs > wouldn't lock either. The only solution was to use a separate DCM to > generate a clock for Chipscope. > > But could the following help: > > Assuming that the amount of logic connected to the output of a DCM does > matter or some nearby output pins add jitter to the input clock, could I > use a BUFGMUX at the output of the DCMs, and use the lock-output of the > DCM as select-signal to switch between the DCM-output and GND? That way > I could disable all logic in the FPGA until the DCMs are locked. > > Until then it seems I have to configure the FPGA twice to get the design > running. > > cu, > Sean >Article: 69901
We can certain meet your requirements with our new product Broaddown2. Look here http://www.enterpoint.co.uk/moelbryn/broaddown2.html . John Adair Enterpoint Ltd. - Home of Broaddown2 http://www.enterpoint.co.uk This message is the personal opinion of the sender and not that necessarily that of Enterpoint Ltd.. Readers should make their own evaluation of the facts. No responsibility for error or inaccuracy is accepted. "Basuki Endah Priyanto" <EBEPriyanto@ntu.edu.sg> wrote in message news:Z6dbuF%23PEHA.2168@exchnews1.main.ntu.edu.sg... > Hello all, > > I am looking for a FPGA board (preferably: Xilinx SPARTAN 100k-300k gates) with flash memory attached on the board itself to store the bit file. > > Anyone can help me or just gimme the URL ? > > Thanks. > > -Basuki- > >Article: 69902
Dear All,
I need to store and process 88 data(each is 8 bits), I use two
dimensional array to define a new data type. My questions are:
1. Is 2-D array synthesizable ?
2. I can't use downto with 2-D array ? such as the followings, which
results in syntax error.
....
type ChipBuffer is array (0 to 87) of std_logic_vector(7 downto 0);
singal ,ChipBuffer_I2 : ChipBuffer ;
....
ChipBuffer_I2(87 downto 1) <= ChipBuffer_I1( 86 downto 0);
error: ChipBuffer_I1 can not be used with range downto;
So what can I use to replace the 2-D array in this case ,
Many thanks!
Jimmy
Article: 69903Jimmy a écrit: > Dear All, > I need to store and process 88 data(each is 8 bits), I use two > dimensional array to define a new data type. My questions are: > 1. Is 2-D array synthesizable ? Not as such, IIRC. Note that your array is not a 2-D array but an array of arrays, which is synthesizable. > 2. I can't use downto with 2-D array ? such as the followings, which > results in syntax error. You can but not as you did (see below) > .... > type ChipBuffer is array (0 to 87) of std_logic_vector(7 downto 0); > singal ,ChipBuffer_I2 : ChipBuffer ; > .... > ChipBuffer_I2(87 downto 1) <= ChipBuffer_I1( 86 downto 0); > > error: ChipBuffer_I1 can not be used with range downto; You declared ChipBuffer type with ascending range, you must use an ascending range when using signals of type ChipBuffer: ChipBuffer_I2(1 to 87) <= ChipBuffer_I1(0 to 86); -- ____ _ __ ___ | _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le - | | | | | (_| |_| | Invalid return address: remove the - |_| |_|_|\__|\___/Article: 69904
Peter, I was referring to hard IP uP, not soft cores. Austin Peter Sommerfeld wrote: > Multiple embedded processors? > > I built a Stratix design with 6 Nios' on it a long time ago. The > design from start to finish took less than half a day. Could have been > more if I had the space on the FPGA. > > -- Pete > > >>Processors, plural. >> >>I'm still right. >> >>Austin >>Article: 69905
Allan, Any suggestions made here are taken seriously by me (at least) and passed along to the ICDES group. The fact that it can be done in the fabric means that it isn't critical, but when we go and poll customers, we may find it is common IP that is similar to all. In that case, the 'Virtex Vortex' takes over, and it gets sucked into the chip (like many other good ideas). Austin Allan Herriman wrote: > On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com> > wrote: > > >>Allan, >> >>Good suggestion. >> >>Timely too. >> >>Thanks, >> >>Austin > > > > Hi Austin, > > Are you hinting that this feature may be added in future silicon? > > Regards, > Allan. > > > > >>Allan Herriman wrote: >> >>>On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com> >>>wrote: >>> >>> >>> >>>>Sean, >>>> >>>>Brute force! >>>> >>>>As long as the locked signal is low, periodically reset the DCM, and see >>>>if the locked signal remains low. >>>> >>>>It takes a little state machine, and it would have to run off the DCM >>>>CLKIN (which is OK, just assume it is running at 25 MHz to calculate how >>>>many counts you need to wait to make sure that LOCKED has gone high). >>>> >>>>Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, >>>>use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset >>>>the DCM). >>>> >>>>(pseudo code below) >>>> >>>>while CLKIN_STOPPED = 1 (clock is running) >>>> >>>> assert (reset for one clock) >>>> wait XX uSec >>>> >>>> check DCM: DCM not operating? (check approp. status) >>>> assert reset (for one clock) >>>> wait XX uSec >>>> else do nothing >>>> >>>> wait XX uSec (use one counter for all waits) >>>> >>>> go to check DCM >>> >>> >>>Hi Austin, >>> >>>Is there any fundamental reason why this logic couldn't be built into >>>the DCM and be enabled/disabled by a config bit? >>> >>>The "wait XX usec" might be a problem, but this could by worked around >>>in a number of ways (e.g. by using psclk as a timing reference, etc.) >>> >>>I find that having to add this state machine to all DCMs just to get >>>them to work reliably is a bit of a pain. >>> >>>Regards, >>>Allan.Article: 69906
Thanks a million to Nicolas Matringe !!!, solve the problem according to your suggestion :-) , Jimmy, "Nicolas Matringe" <matringe.nicolas@numeri-cable.fr> wrote in message news:40B1FF2B.3090702@numeri-cable.fr... > Jimmy a écrit: > > Dear All, > > I need to store and process 88 data(each is 8 bits), I use two > > dimensional array to define a new data type. My questions are: > > 1. Is 2-D array synthesizable ? > > Not as such, IIRC. > Note that your array is not a 2-D array but an array of arrays, which is > synthesizable. > > > > 2. I can't use downto with 2-D array ? such as the followings, which > > results in syntax error. > > You can but not as you did (see below) > > > > .... > > type ChipBuffer is array (0 to 87) of std_logic_vector(7 downto 0); > > singal ,ChipBuffer_I2 : ChipBuffer ; > > .... > > ChipBuffer_I2(87 downto 1) <= ChipBuffer_I1( 86 downto 0); > > > > error: ChipBuffer_I1 can not be used with range downto; > > You declared ChipBuffer type with ascending range, you must use an > ascending range when using signals of type ChipBuffer: > ChipBuffer_I2(1 to 87) <= ChipBuffer_I1(0 to 86); > > -- > ____ _ __ ___ > | _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le - > | | | | | (_| |_| | Invalid return address: remove the - > |_| |_|_|\__|\___/ >Article: 69907
On Mon, 24 May 2004 07:25:34 -0700, Austin Lesea <austin@xilinx.com> wrote: >Allan, > >Any suggestions made here are taken seriously by me (at least) and >passed along to the ICDES group. Good. The "auto-DCM-relocker" will need the following features (at least): 1. Auto-relock feature can be disabled by a config bit, which allows "good 'ol mode" to be emulated. Auto-relock will be off by default. 2. There needs to be a new status bit which indicates that the auto-relock feature has been active (to aid fault finding, etc.). This bit would be reset by a) config and b) user reset of DCM. How would you expect to implement the "wait XX uSec" part of the design? Every FPGA design I've ever done has had a reliable (i.e. not via a DLL, PLL or DCM) clock somewhere in the range 2MHz to 50MHz. Such a clock could be connected to the PSCLK input of the DCM (or perhaps a new input?) and there would be a new DCM attribute to indicate the freq / period of this clock. Or maybe you can do it with analog delays on the chip (?) Regards, Allan. > >The fact that it can be done in the fabric means that it isn't critical, >but when we go and poll customers, we may find it is common IP that is >similar to all. In that case, the 'Virtex Vortex' takes over, and it >gets sucked into the chip (like many other good ideas). > >Austin > >Allan Herriman wrote: > >> On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com> >> wrote: >> >> >>>Allan, >>> >>>Good suggestion. >>> >>>Timely too. >>> >>>Thanks, >>> >>>Austin >> >> >> >> Hi Austin, >> >> Are you hinting that this feature may be added in future silicon? >> >> Regards, >> Allan. >> >> >> >> >>>Allan Herriman wrote: >>> >>>>On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com> >>>>wrote: >>>> >>>> >>>> >>>>>Sean, >>>>> >>>>>Brute force! >>>>> >>>>>As long as the locked signal is low, periodically reset the DCM, and see >>>>>if the locked signal remains low. >>>>> >>>>>It takes a little state machine, and it would have to run off the DCM >>>>>CLKIN (which is OK, just assume it is running at 25 MHz to calculate how >>>>>many counts you need to wait to make sure that LOCKED has gone high). >>>>> >>>>>Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, >>>>>use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset >>>>>the DCM). >>>>> >>>>>(pseudo code below) >>>>> >>>>>while CLKIN_STOPPED = 1 (clock is running) >>>>> >>>>> assert (reset for one clock) >>>>> wait XX uSec >>>>> >>>>> check DCM: DCM not operating? (check approp. status) >>>>> assert reset (for one clock) >>>>> wait XX uSec >>>>> else do nothing >>>>> >>>>> wait XX uSec (use one counter for all waits) >>>>> >>>>> go to check DCM >>>> >>>> >>>>Hi Austin, >>>> >>>>Is there any fundamental reason why this logic couldn't be built into >>>>the DCM and be enabled/disabled by a config bit? >>>> >>>>The "wait XX usec" might be a problem, but this could by worked around >>>>in a number of ways (e.g. by using psclk as a timing reference, etc.) >>>> >>>>I find that having to add this state machine to all DCMs just to get >>>>them to work reliably is a bit of a pain. >>>> >>>>Regards, >>>>Allan.Article: 69908
John Adair wrote: > If you want to make your logic "quiet" I would suggest using a set/reset or > clock enable as the simplest way. This isn't going to solve issues after > locking. I don't have any issues after locking, my problem is the DCMs not locking in the first place. After they've locked, everything works fine, the output clock is as perfect as it gets coming from a DCM, and they never lose lock again. The entire design is kept in reset until all DCMs have locked. In one variant the design will never come out of reset, since the DCMs never lock, even though at that particular time no outputs are active at all, or at least they shouldn't be switching; so there should be no power noise added from switching I/Os as far as I understand it... > I might have missed it in the thread but is your Vccaux connected in any > way to a Vcco rail ? If it isn't please ignore the following: It is, but this is more or less a finished product and I can't do anything about it now. But I'll keep that in mind for future designs. > Statement - 2 designs that are similar at HDL level may be very different > designs after synthesis. mapping and p&r. Yes, that's right, the whole design flow seems rather "chaotic" :) cu, SeanArticle: 69909
Hi all, I have some test programs for a device that have been developed inside a verilog testbench; the result of the simulation is an EVCD file that I am able to convert to WGL and ASC. The issue is that I need to get a SVF version of it... Does anybody knows of a tool that can convert my EVCD or WGL or ASC stimuli to SVF? Thanks & Regards, SteveArticle: 69910
Allan, I will let the ICDES folks solve the problems. It is enough that we specify the feature! Since the DCM is entirely digital (state machines and delay lines), it is pretty trivial to see if the states are progressing, stuck, or not valid. Austin Allan Herriman wrote: > On Mon, 24 May 2004 07:25:34 -0700, Austin Lesea <austin@xilinx.com> > wrote: > > >>Allan, >> >>Any suggestions made here are taken seriously by me (at least) and >>passed along to the ICDES group. > > > Good. The "auto-DCM-relocker" will need the following features (at > least): > > 1. Auto-relock feature can be disabled by a config bit, which allows > "good 'ol mode" to be emulated. Auto-relock will be off by default. > > 2. There needs to be a new status bit which indicates that the > auto-relock feature has been active (to aid fault finding, etc.). > This bit would be reset by a) config and b) user reset of DCM. > > > How would you expect to implement the "wait XX uSec" part of the > design? Every FPGA design I've ever done has had a reliable (i.e. not > via a DLL, PLL or DCM) clock somewhere in the range 2MHz to 50MHz. > Such a clock could be connected to the PSCLK input of the DCM (or > perhaps a new input?) and there would be a new DCM attribute to > indicate the freq / period of this clock. > Or maybe you can do it with analog delays on the chip (?) > > Regards, > Allan. > > >>The fact that it can be done in the fabric means that it isn't critical, >>but when we go and poll customers, we may find it is common IP that is >>similar to all. In that case, the 'Virtex Vortex' takes over, and it >>gets sucked into the chip (like many other good ideas). >> >>Austin >> >>Allan Herriman wrote: >> >> >>>On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com> >>>wrote: >>> >>> >>> >>>>Allan, >>>> >>>>Good suggestion. >>>> >>>>Timely too. >>>> >>>>Thanks, >>>> >>>>Austin >>> >>> >>> >>>Hi Austin, >>> >>>Are you hinting that this feature may be added in future silicon? >>> >>>Regards, >>>Allan. >>> >>> >>> >>> >>> >>>>Allan Herriman wrote: >>>> >>>> >>>>>On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com> >>>>>wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Sean, >>>>>> >>>>>>Brute force! >>>>>> >>>>>>As long as the locked signal is low, periodically reset the DCM, and see >>>>>>if the locked signal remains low. >>>>>> >>>>>>It takes a little state machine, and it would have to run off the DCM >>>>>>CLKIN (which is OK, just assume it is running at 25 MHz to calculate how >>>>>>many counts you need to wait to make sure that LOCKED has gone high). >>>>>> >>>>>>Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, >>>>>>use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset >>>>>>the DCM). >>>>>> >>>>>>(pseudo code below) >>>>>> >>>>>>while CLKIN_STOPPED = 1 (clock is running) >>>>>> >>>>>> assert (reset for one clock) >>>>>> wait XX uSec >>>>>> >>>>>> check DCM: DCM not operating? (check approp. status) >>>>>> assert reset (for one clock) >>>>>> wait XX uSec >>>>>> else do nothing >>>>>> >>>>>> wait XX uSec (use one counter for all waits) >>>>>> >>>>>> go to check DCM >>>>> >>>>> >>>>>Hi Austin, >>>>> >>>>>Is there any fundamental reason why this logic couldn't be built into >>>>>the DCM and be enabled/disabled by a config bit? >>>>> >>>>>The "wait XX usec" might be a problem, but this could by worked around >>>>>in a number of ways (e.g. by using psclk as a timing reference, etc.) >>>>> >>>>>I find that having to add this state machine to all DCMs just to get >>>>>them to work reliably is a bit of a pain. >>>>> >>>>>Regards, >>>>>Allan. > >Article: 69911
Sean, One issue with the DCM's is that they need the CLKFB input stable when they start if they are to lock. A common problem is that the CLKIN, or the CLKFB (or both) are not stable when DONE goes high, so the DCM fails to lock. A subsequent reset usually solves this problem. Again, it sounds like you should send this to the hotline, as they are well versed in getting to the root of these issues, Austin Sean Durkin wrote: > John Adair wrote: > >> If you want to make your logic "quiet" I would suggest using a >> set/reset or >> clock enable as the simplest way. This isn't going to solve issues after >> locking. > > I don't have any issues after locking, my problem is the DCMs not > locking in the first place. After they've locked, everything works fine, > the output clock is as perfect as it gets coming from a DCM, and they > never lose lock again. > The entire design is kept in reset until all DCMs have locked. In one > variant the design will never come out of reset, since the DCMs never > lock, even though at that particular time no outputs are active at all, > or at least they shouldn't be switching; so there should be no power > noise added from switching I/Os as far as I understand it... > >> I might have missed it in the thread but is your Vccaux connected in any >> way to a Vcco rail ? If it isn't please ignore the following: > > It is, but this is more or less a finished product and I can't do > anything about it now. But I'll keep that in mind for future designs. > >> Statement - 2 designs that are similar at HDL level may be very different >> designs after synthesis. mapping and p&r. > > Yes, that's right, the whole design flow seems rather "chaotic" :) > > cu, > SeanArticle: 69912
"ds" <nospam@thankyou.nl> wrote in message news:40292c93$0$32739$4a441750@news.euronet.nl... > Sometimes you need a quick routine, or a routine that uses encryption. > Sometimes you need a simple multiplication of Big numbers... > If so, we would like to know we developed a collection > of functions (library, dll) for working with real big numbers and all that. > (...numbers bigger than the normal data types a programmer can handle.) > > It was made for Visual Basic, but can be used in > any language that can invoke a .DLL (such as C++, VBA in Excel, Access or > whatever) > > It's the only DLL available for Windows for UNLIMITED BIG NUMBERS with > functions such as: +/-* Power2, Power10, MOD DIVIDE, ISPRIME, COMPARE, Xor exponent squaring? > etc... > > Calculations are sometimes even faster than you are used to, > cause everything was made in assembly. For which cpu's have you been optimizing? % and / are very slow operations at most cpu's. 64 bits? > It's shareware and it is online on http://www.big-numbers.com > DavidArticle: 69913
The only interesting thing is whether your library is faster at x86-64 than the GNU tools. The rest doesn't count. "ds" <nospam@thankyou.nl> wrote in message news:40294431$0$98746$d5255a0c@news.wanadoo.nl... > Oh, can it also be used in Visual Basic? On a Win 98 machine ? > Can it also find all 100% proven Prime Numbers? > Can it also find RSA-factors ?... > Does it include encryption modules? > > Oh.... > --- > Just restoring balance... > > David > > "Marius Vollmer" <marius.vollmer@uni-dortmund.de> schreef in bericht > news:ljr7x2brup.fsf@troy.dt.e-technik.uni-dortmund.de... > > "ds" <nospam@thankyou.nl> writes: > > > > > It's the only DLL available for Windows for UNLIMITED BIG NUMBERS with > > > functions such as: +/-* Power2, Power10, MOD DIVIDE, ISPRIME, COMPARE, > Xor > > > etc... > > > > To restore balance to the force, I'd ike to mention GNU MP: > > > > http://www.gnu.org/software/gmp > > > > which has most if not all of the features of the above DLL and is Free > > Software (i.e., comes with full source code). > >Article: 69914
vbishtei@hotmail.com (vadim) wrote in message news:<2a613f5d.0405231856.56b8c5ae@posting.google.com>... > I was fully aware that the MAX CPLD was programming the Stratix > device. We tried > to find the pin that is connected to the MAX CPLD and program it to be > tied to VCC (reconfig_req_n). This failed. > I was not aware there was a software setting inside Quartus to > Tri-State unused pins, which only found through this newsgroup (thing > like this should appear > on the front pages of the NIOS Board manual). > > Generally, from working and learning Altera devices and software a > pattern seems to emerge - bad and ambiguous documentation. Huge and > wordy documents > that don't state the "beef" but tend to repeat things without much > elaboration. > This reminded me of learning Cadence software... > Hi Vadim, I'm sorry that this problem caused you any trouble. With regards to documentation, I think a lot of people feel the same way. The unfortunate thing is that some readers need a lot of hand-holding when getting started with a new tool, while some prefer the 'beef' as you mention (I personally prefer the no-nonsense brief approach myself). I think an ideal solution would be to have the verbose, and then ultra-brief versions of select documents. This is, of course, very difficult when shipping a product as the documentation tends to require a completed product from the engineering standpoint and it's a real rush to get all the docs done correctly when the product is nearly ready to go. Anyways, about this issue specifically: There is now a warning that is called out of regular text (i.e., not just a paragraph) in the Nios II HW development tutorial that tells the reader to change this setting before starting Quartus compilation. The revised tutorial is up on our web site and will ship on the Nios II CDs shortly. Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 69915
albert@spenarnc.xs4all.nl (Albert van der Horst) wrote in message news:<Hy5wHL.1nz.1.spenarn@spenarnc.xs4all.nl>... > In article <adb3971c.0405222015.4821eb9@posting.google.com>, > john jakson <johnjakson@yahoo.com> wrote: > > <SNIP> > >I just realised, you probably don't need to look at the Transputer > >because it has no sp type stack that you'd need for Forth, Pascal, C > >etc. It does have a HW stack for eval expressions just like a HP RPN > >calc but it is only 3 reg deep and tied into the scheduler for > >switching processes when its empty IIRC.. > > It is not the stack (or a stack). These are registers at the lowest > level, almost a RISC way to write microcode explicitly. > The register at the next to lowest level are 16, and you can add two > registers and put it back in a third by 3 single byte instructions. > You can use a couple of those for stack pointers, without exhausting > resources, like in a Pentium. > > <SNIP> > > > >A google for Transputer & Forth should draw a blank I'd guess but I > >could be wrong. > > Of course you are wrong. > You should know by now, that there is a Forth for every processor > that is over 6 month old. > Ofcourse I checked on the next line before signing off, and saw tforth and others > tforth is the precursor is iforth, and it is still available from DFW. > It is a solid piece of work, if I may say so myself. > There are more. > > >Yes it does look like they did it, well I wonder what they did? > > > >regards > > > >johnjakson_usa_comArticle: 69916
A wild guest, it would well fit in spartan2 100 :)Article: 69917
Jesse Kempa wrote: > As an example, the user can debug many (we have tested up to > 8) processorS (plural) simultaneously via a single JTAG connection and > a nice IDE environment. This is where we are today, but it just doesn't play to the strength of an FPGA. It's a bit like having one (or 8) block RAM. The FPGA really gets rolling when we can make parallel use of a shed-load of resources. Just as nothing can beat the bandwidth of a big FPGA with all the block RAMs going in parallel, nothing will be able to touch an FPGA with lots of application-tailored CPUs. Not great for evaluating spreadsheets, but pretty good in other domains. I once had a project (paper only) where each processor's instruction stream was scanned for the opcodes used, then the corresponding FPGA processor implementation was modified to match the usage.Article: 69918
Now I am doing Xilinx Virtex2 (xc2v1000) readback to capture register status. I have done C++ code for this, but it doesn't work at all. After I send the CFG_IN(000101) instruction, the command is following: aa995566h(sync word); 30002001h(write to FAR register); Frameaddr(from the .ll file); 30008001h(write to CMD register); 00000004h(RCFG); 280060d4h(Number of word to readback)(3392 Bit/Frame 106x 32 for xc2v1000. 212(d4h)x32) 00000000h;flush the command pipeline. 00000000h;flush the command pipeline.(64 Bit register) I think, the virtex2 is same with virtex. The value for one frame readback word is 2 times the Frame Bit. The first 3392 Bit is pad frame. then is CLB frame. then after the CFG_OUT(000100) instruction, ignore the first 3392 bit, after that readback from TDO when offset (from .ll file) plus 32(pad word). I instantiated the capture_virtex2. So I don't know how to do it. Have anyone idea to do it? Any informtion is welcome. Thanks in advance.Article: 69919
In article <c8tdmh$8o2$1$8300dec7@news.demon.co.uk>, Tim <tim@rockylogic.com.nooospam.com> wrote: >Jesse Kempa wrote: > >> As an example, the user can debug many (we have tested up to >> 8) processorS (plural) simultaneously via a single JTAG connection and >> a nice IDE environment. > >This is where we are today, but it just doesn't play to the strength of >an FPGA. It's a bit like having one (or 8) block RAM. The FPGA really >gets rolling when we can make parallel use of a shed-load of resources. >Just as nothing can beat the bandwidth of a big FPGA with all the block >RAMs going in parallel, nothing will be able to touch an FPGA with lots >of application-tailored CPUs. > >Not great for evaluating spreadsheets, but pretty good in other domains. Surely spreadsheets are pretty much infinitely parallel once you've spread up the dependency graph for the cells among the various processors ... word processing is the bit I have more trouble thinking how to divide among a myriad processors, not that anyone types fast enough for that to matter :) TomArticle: 69920
I fully agree with Ray. When it comes to high bandwidth bidir communication, your only cost effective solution is serial io. 3 to 5 cm is not a big distance, but be aware at 2.5Gbps and above, PCB design is not very straight forward. Differences in trace length, cross-over distortion, etc. are things that you will have to deal with. Robustness of the serdes, easy of programming, jitter tolerance, ... are very important. Regards On Thu, 05 Feb 2004 08:15:07 -0500, Ray Andraka <ray@andraka.com> wrote: >From a cost standpoint, that is not always true. Also, if you have a >memory intensive application, you get more memory by using two smaller >devices (say XC2V3000's) instead of one larger one (eg XC2V6000). If >you have the luxury of using a chip with the high speed serial i/o, >that will give you rather high bandwidth connections without using up >many pins. Otherwise, you need to refer to the data sheets for each of >the i/o standards supported to see the speeds and what is required to >make it work. Some of the lower voltage swings are faster, but have >special voltage requirements you may not be able to meet. LVDS is >generally faster, at least on longer runs. You may need external >terminators as well, as IIRC, invoking the DCI has a substantial speed >penalty. > >Uwe Bonnes wrote: > >> Griva <griva@poczta.onet.pl> wrote: >> : Hi, >> >> : I'm looking for the fastest interface/standard between two FPGAs. >> : Have You got any suggestions? >> >> It depends on reuirements: >> - Uni/Bidirectional >> - Distance between chips >> - Number of connections allowed >> ... >> >> I think that nearly always it is best to get a bigger FPGA and put >> everything into one package. >> >> Bye >> -- >> Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de >> >> Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt >> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 69921
hello guys, I am working on a verilog design. But the top level module is written in handel-C. First i synthesised the verilog design with the synthesis option 'Add I/O buffers' unchecked. it generated .ngc file. the synthesis report showed that the design used some 280 slices of the device considered. Next while running NGDBUILD for the top level module, i used the ngc file generated, as it has to merge the two source files and create a single file. But while i am doing this i am getting several warnings as: WARNING:NgdBuild:454 - logical net 'W168_send_protocol_56_main' has no load WARNING:NgdBuild:454 - logical net 'W169_send_protocol_56_main' has no load WARNING:NgdBuild:454 - logical net 'W170_send_protocol_56_main' has no load WARNING:NgdBuild:454 - logical net 'W171_send_protocol_56_main' has no load WARNING:NgdBuild:454 - logical net 'W172_send_protocol_56_main' has no load ... send_protocol is the top level design name. And the synthesis report shows that the design uses only 324 slices. i dont understand what the problem is. could anyone please help me. thanks, kumarArticle: 69922
td@emu.com (Tony Dean) wrote in message news:<33aa9b10.0405181256.7895fada@posting.google.com>... > I have the same requirement and have successfully generated a reset > signal for the CLKDLL, so I know it can be done. It looks something > like this: > > dll : CLKDLL port map ( > CLKIN => clk, > CLKFB => clkfb, > RST => dll_reset, > etc. > ); > > dll_reset <= error1 OR error2; -- error1, error2 generated by internal > logic > > Good luck! > -td Hi Thanks a lot.. I tried to generate a reset signal for the DLL from the above mentioned logic and I found the same errors as it was before. I guess its not because of the bad logic and I am not sure whether the rest of the design (apart from the using DLL) has logical errors. I have been using Xilinx ISE 6.2i and the service pack of the current version is updated as well. Also. I have gotten new warnings... ******************** Checking timing specifications ... Checking expanded design ... WARNING:NgdBuild:488 - Attribute value "LVCMOS25" is not an accepted value for attribute "IOSTANDARD" on "Clock_x4_rstpad". WARNING:NgdBuild:488 - Attribute value "LVCMOS25" is not an accepted value for attribute "IOSTANDARD" on "mod_clk_x2_rstpad". WARNING:NgdBuild:488 - Attribute value "LVCMOS25" is not an accepted value for attribute "IOSTANDARD" on "Clock_x4_clkpad". WARNING:NgdBuild:488 - Attribute value "LVCMOS25" is not an accepted value for attribute "IOSTANDARD" on "mod_clk_x2_clk40_pad". ******************* The error list also denote me that the reset signal has illegal connection and in the .ngr file, I see the illegal connection that I havent mentioned in the design. Eagerly waiting for ur suggestions... Thanks in advance.. grüss RajeshArticle: 69923
Altera finally wakes up. They realize that the window register type architecture is not good for FPGAs and probably in general. They can no longer support their own marketing hype about how great Nios I is. If Nios 1 was so great, why did it need a complete redesign and rearchitecture? It means it was poor. That's the only reason you do a complete redesign. I believe they have switched to 32 bit instructions also. Didn't it used to be 16 bit? Guess that wasn't so great either. They copy the Xilinx Microblaze style implementation. To me it shows who knows what about designing and running a soft processor in an FPGA. Enough said. They throw all the current Nios customers under the bus. Requires publishing a 38 page app note to switch a Nios 1 to Nios II design. Current Nios users, I feel sorry for you. Be careful and do your back ups!Article: 69924
Does anybody out there have a working design using a virtex 2 with an "FG" package type and HSTL signals? Currently I have a design with an HSTL clock coming from the fpga to a self-terminating Samsung QDR memory. I am having major problems getting it to work. As I increase the frequency the amplitude of the signal decreases. At 25 MHz I get a 1.4 V signal, and at 100 MHz I get a 200 mV signal. The memory does not even work until a clock speed of 130 MHz can be reached. I am aware of designs using a virtex 2 with an "FF" package type. I don't want to go into detail but I have performed several tests and am suspecting there is something wrong with the virtex 2 "FG" package type and HSTL signals. If anybody out there can tell me they have something working it would tell me that I am wrong and it is something else. Please only reply if you have an actual working board or if you have also failed to make a "FG" virtex 2 part work. Here is some information on the traces, It is a point to point connection less than 3/4 of an inch the line impedence was measured with TDR and it is between 50 and 53 ohms
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