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
Jim Granville wrote:
> With a simple core, that is not clock constrained (ie spare cycles at
> the core), how feasible is it to time-share that core, with two
> code/data streams, so effectively you see two independant
> 'multi-processor' cores ?
This should be easy. The only states in the core are A, SP, RP and PC,
which have to be swapped.
But instead doing it on the hardware level, I think it would be better to
do it in software: First the CPU needs to be enhanced to allow interrupts
and to load/save the SP and RP registers. Then you can implement a
scheduler for as many threads you want.
> Not sure if I have mentioned IEC 61131 Instruction List pgm before, but
> this looks fairly close to that.
I don't know IL, but it looks a bit too low-level. Creating a function like
decribed at http://www.61131.com/il.htm would look like this in Forth (the
stack notation in parantheses ( s _r -- ) is only a comment and can be
omitted)
value q
: sr ( s _r -- ) q and or to q ;
Then you can test it interactively at the Forth command prompt ("q ." shows
the current value of q. Anything after "\" in a line is comment)
1 1 sr q . \ set flipflop
1 ok
0 1 sr q . \ set input = 0 => q is not changed
1 ok
0 0 sr q . \ reset flipflop
0 ok
Maybe an IL core could be a bit smaller, because it doesn't have a data
stack, but I think programs would be larger and are more difficult to write
and maintain than Forth programs.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Article: 121201On Jun 25, 10:59 pm, Allen <lphp...@gmail.com> wrote: > hi, guys > > We design a hardware written in Verilog and synthesize by Synopsys > Design Vision. > > The post-synthesis simulation is shown that the function of hardware > is correct. > > Now, we are going to verify function of hardware by downloading it to > Xilinx FPGA. > > We synthsize the hardware design by using ISE 7.1i. Unfortunately, the > post-synthesis simulation failed ( all the output is unknown or high- > impeadance). I tried to synthesize with keeping hierarchy, but it > still unuseful. > > What can I do next step? We don't have much experience in this field. > > Thanks. > > Regards It could be that you don't have it connected properly in your test bench. If all of the outputs are unknown, then the inputs are probably unknown too. Some probing with your simulator should find it. I'd start with clock & reset. G.Article: 121202
On 2007-06-27, gamer <csanjay@gmail.com> wrote: > else if (~matched) > for (i=0; i<datawidth; i=i+1) > error_count = error_count + mismatch[i]; Although from a software (and possibly a simulation) perspective, that looks like it should reduce the workload by computing 'matched' and "avoiding" the loop if it is not needed, in hardware your speed is going to be limited by the worst case (and the additions are happening all the time, only the enables on the error_count register are affected by your 'if'). If you must have your answer on the very next clock, your options are severely limited. If you only care about the answer occasionally (or with a fixed latency that's greater than one clock), think about how you can take advantage of that. To follow along your original lines of thinking: If you can really find 'matched' at your desired clockrate, and it is infrequent, then you could stuff 'mismatch' into a fifo whenever it's nonzero and add it in a separate loop which only has to keep up with the worst case bit error rate. Or, if, as you said, the process is fast enough for 1 bit, make yourself 'datawidth' 1-bit error counters and add their results whenever you want the total number of errors. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 121203
Frank Buss wrote:
> Jim Granville wrote:
>
>
>>With a simple core, that is not clock constrained (ie spare cycles at
>>the core), how feasible is it to time-share that core, with two
>>code/data streams, so effectively you see two independant
>>'multi-processor' cores ?
>
>
> This should be easy. The only states in the core are A, SP, RP and PC,
> which have to be swapped.
>
> But instead doing it on the hardware level, I think it would be better to
> do it in software: First the CPU needs to be enhanced to allow interrupts
> and to load/save the SP and RP registers. Then you can implement a
> scheduler for as many threads you want.
That's the more conventional way, but I like the deterministic nature of
hardware time-sliced cores - and they can of course, also run interrupts
(giving SW threads on the HW threads.. :).
The problem with interrupts, is the more complex a system is, the bigger
the jitters become. With HW timeslice, each task is invisible to the
other, in the time domain, and they need to share some data to communicate.
>
>>Not sure if I have mentioned IEC 61131 Instruction List pgm before, but
>>this looks fairly close to that.
>
>
> I don't know IL, but it looks a bit too low-level. Creating a function like
> decribed at http://www.61131.com/il.htm would look like this in Forth (the
> stack notation in parantheses ( s _r -- ) is only a comment and can be
> omitted)
>
> value q
> : sr ( s _r -- ) q and or to q ;
>
> Then you can test it interactively at the Forth command prompt ("q ." shows
> the current value of q. Anything after "\" in a line is comment)
>
> 1 1 sr q . \ set flipflop
> 1 ok
>
> 0 1 sr q . \ set input = 0 => q is not changed
> 1 ok
>
> 0 0 sr q . \ reset flipflop
> 0 ok
>
> Maybe an IL core could be a bit smaller, because it doesn't have a data
> stack, but I think programs would be larger and are more difficult to write
> and maintain than Forth programs.
IL does allow brackets, and expressions inside the brackets evaluate
first, just like in maths, and that gives a Data Stack.
So the IL 'Assembler/Compiler' would have to generate the opcodes to
support the stack to support the brackets.
-jg
Article: 121204
On 2007-06-28, Albert Nguyen <> wrote:
> I have a specific application where the FPGA needs to generate SPI
>
> The problem is that the traget device will have its vcc at 1.2V and and its Vee at -1.3V.
All SPI signals are unidirectional, so you should be able to level shift
with a few transistors. Why not:
Vcc
+
|
|
1k_ |<
[SCK>---|___|--|
|\ |
o-------.
.-. |
| | | ---
500| | --- 10p "load"
'-' | |
o-------'
| |
===
Vee
SCK high is > 1.2V, SCK low < 1.2V. Be sure to park SCK low, and invert
the signals...
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
--
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/
Article: 121205"Xilinx User" <anonymous@net.com> wrote in message news:h1Dgi.4487$vi5.1602@newssvr17.news.prodigy.net... snip > i was going to suggest buying a few XE-III (full) licenses, > but that was contingent upon, apparently, an > undocumented/unofficial support for Systemverilog. Now, > I'll probably suggest getting (Mentor) Modelsim-PE. > > Anyway, Modelsim XE-III 6.2c starter-edition ran > Systemverilog simulations just fine. So did Xilinx remove > this feature from XE-III 6.2g? Nowhere in Xilinx's > online documentation, does Xilinx claim to support > Systemverilog. But I'd like to get a definitive/official > answer. If this is indeed the case then I believe Mentor has changed their OEM agreement with Xilinx since the difference has always been simulation speed and number of instances. This might just been an oversight on Xilinx's part? Do you have the sv_std folder in your installation directory? (I have it on my PE installation). Hans www.ht-lab.comArticle: 121206
Gents, please allow me to confront you with some strange timing behaviour which I have measured with an Xilinx XC95108 cpld. Consider two well conditioned clock signals of 10 MHz (both having EXACTLY the same frequency) entering the cpld. Inside the cpld each clock signal is divided by 4 by means of two d-flip-flops. The two resulting 2.5 Mhz signals enter an exclusive-or-gate which delivers an output signal where the pulse/pause-relationship directly depends on the phase relationship of the two input clocks. If some of you feel reminded to something that you have seen before: Yes, basically this is the principle of an so called linear phase comparator which has been used to compare high stability clocks (for example cesium clocks) against each other before high resolution time interval counters like the HP5370 or the Stanford Research SR620 were available. Now imagine one of the two clocks is de-tuned by exactly 0.001 Hz. It is a bit beyond the discussion HOW this is achieved but you may believe me that this is possible and that THIS is not part of the discussed problem. Now the phase relationship of the clocks changes slowly in time as does the pulse/pause relationship behind the xor gate. The pulse/pause relationship of the xor's output can be measured by two completely different methods: a) by generating an dc voltage which is directly proportional to the pulse/pause relationship (again a bit tricky if you want it to be an really high resolution measurement, but it can be done) b) by directly measuring the output pulse width with an high resolution time interval counter like the SR620 having a 25 ps single shot resolution for time interval measurements. It is important to note that both methods to measure can be applied at the same time and that both methods (although based on completely different physical laws) deliver results that despite some statistical fluctuations are basically the same. That is why I am pretty sure that what I measure is really an property of the signal itself and not one of the measurement apparatus. If I record the pulse width over time using the two methods and display it graphically it looks like an pretty linear relationship at the first glance. If however some math is applied to make it evident how good the linear relationship really is met then the result is that there are fluctuations in the pulse width in the order of some +/-450 ps from the expected values. About these fluctuations the following facts are known: 1) They are not existent in the inputs clocks 2) Expressed in time units as well as expressed as an dc voltage the fluctuations are orders of magnitude bigger than the resolution and precision of the time/dc measurement. 3) The fluctuations are by no means of stochastical nature. Instead, If an positive fluctuation is noticed at an certain phase between the clock signals, an fluctuation of the same magnitude and sign will be noticed the next time when the clock signals have the same phase relationship. Or in other words: The pulse width is an direct function of the phase relationship of the clocks + an error function which is an direct function of the phase relationship between the clocks. It seems as if the phase state of one of the signals can have an linear like modulating effect on the phase state of the second signal (and perhaps vice versa). Some of you may come to the conclusion that +/-450 ps is not an number to cause real world troubles but in my case: The whole arrangement has the intention to measure phase fluctuations of the input clocks that ARE REALLY THERE but that are smaller at least one order of magnitude than the noticed errors. And that is why +/-450 ps is an real annoying number for me. Any hint will be highly appreciated TIA, Ulrich BangertArticle: 121207
Hi Can anyone tell me what Xilinx have done to the timing summary in ISE 9.1. In 8.2 it used to give you what you requested and by how much it was met. In 9.1 it has changed with reference to MAXDELAY which I have not even set. Cheers JonArticle: 121208
Thank you for kind offer, but I have managed it. There was some problem with the ide, which crashed at the very end the first time round, something error in line 570 very dubious, but then I just did it again with a new project and it did work. I shall need some help with my programmer, maybe you will be available, I am waiting for it to arrive from my ebay seller. BTW, how did you learn how to use the schematic editor? ...and what is the difference between and2 and2b1 and2b2 Thanks Arlen > Be sure to place I/O markers at the input and outputs. Otherwise, > you will get an error. Highlight the top level schematic in > the source window. In the process window below expand > 'User Constraints' and double click 'Assign package pins'. > Answer 'Yes' to create constraint file. The program > Xilinx Pace should start. In the 'Design Browser' window > expand the 'I/O Pins' tree list. Drag each pin to the > desired available I/O pin. Save and close. > You can implement a design without assigning pins. It will > automatically place the I/O pins at the most effecient > place. This is useful when designing a new board, and you > want optimun placement and performance. > > Ensure the top level schematic is still highlighted. > In the process window double click 'Implement Design'. > > Review the log window below for any errors. > > I can email you a zipped AND gate project if you want!Article: 121209
Ulrich Bangert wrote: > Gents, > > please allow me to confront you with some strange timing behaviour which I > have measured with an Xilinx XC95108 cpld. > > Consider two well conditioned clock signals of 10 MHz (both having EXACTLY > the same frequency) entering the cpld. Inside the cpld each clock signal is > divided by 4 by means of two d-flip-flops. The two resulting 2.5 Mhz signals > enter an exclusive-or-gate which delivers an output signal where the > pulse/pause-relationship directly depends on the phase relationship of the > two input clocks. > > If some of you feel reminded to something that you have seen before: Yes, > basically this is the principle of an so called linear phase comparator > which has been used to compare high stability clocks (for example cesium > clocks) against each other before high resolution time interval counters > like the HP5370 or the Stanford Research SR620 were available. > > Now imagine one of the two clocks is de-tuned by exactly 0.001 Hz. It is a > bit beyond the discussion HOW this is achieved but you may believe me that > this is possible and that THIS is not part of the discussed problem. Now the > phase relationship of the clocks changes slowly in time as does the > pulse/pause relationship behind the xor gate. The pulse/pause relationship > of the xor's output can be measured by two completely different methods: > > a) by generating an dc voltage which is directly proportional to the > pulse/pause relationship (again a bit tricky if you want it to be an really > high resolution measurement, but it can be done) > > b) by directly measuring the output pulse width with an high resolution time > interval counter like the SR620 having a 25 ps single shot resolution for > time interval measurements. > > It is important to note that both methods to measure can be applied at the > same time and that both methods (although based on completely different > physical laws) deliver results that despite some statistical fluctuations > are basically the same. That is why I am pretty sure that what I measure is > really an property of the signal itself and not one of the measurement > apparatus. > > If I record the pulse width over time using the two methods and display it > graphically it looks like an pretty linear relationship at the first glance. > If however some math is applied to make it evident how good the linear > relationship really is met then the result is that there are fluctuations in > the pulse width in the order of some +/-450 ps from the expected values. > > About these fluctuations the following facts are known: > > 1) They are not existent in the inputs clocks > > 2) Expressed in time units as well as expressed as an dc voltage the > fluctuations are orders of magnitude bigger than the resolution and > precision of the time/dc measurement. > > 3) The fluctuations are by no means of stochastical nature. Instead, If an > positive fluctuation is noticed at an certain phase between the clock > signals, an fluctuation of the same magnitude and sign will be noticed the > next time when the clock signals have the same phase relationship. Or in > other words: The pulse width is an direct function of the phase relationship > of the clocks + an error function which is an direct function of the phase > relationship between the clocks. How often do you see this, 4 or 8 times per 2.5MHz cycle ? > > It seems as if the phase state of one of the signals can have an linear like > modulating effect on the phase state of the second signal (and perhaps vice > versa). Some of you may come to the conclusion that +/-450 ps is not an > number to cause real world troubles but in my case: The whole arrangement > has the intention to measure phase fluctuations of the input clocks that ARE > REALLY THERE but that are smaller at least one order of magnitude than the > noticed errors. And that is why +/-450 ps is an real annoying number for me. > > Any hint will be highly appreciated > TIA, Ulrich Bangert I think I have followed this. If you are trying to 'zoom into' the phase to high precisons, using analog Phase integration, there are some rules to follow. Vcc and Gnd must be VERY clean. That means no other clocks, and /4 is going to cause more edges and bounce, plus Vdd impedance noise is usually quite bad on CPLDs. Any edge that is very close to another, WILL move the threshold, and so cause phase non-linearities. Normally, these are so small, well under Tpd, so in the digital domain they do not matter much. [Some CPLDs will show Tpd delta, vs outputs loded ] This stuff is NOT on the chip designer's radar :) So, do not use a CPLD as the Phase Comparitor, but use an LVC Exor gate, preferable with Schmitt. eg LVC1G97, with analog Supply decoupling. You may even find, you cannot have both non-locked frequencies in the same package, so may need separate /4 blocks Also XOR gates will be quite good at 90' output, but will not be linear at needle pulse phase outputs, so if you need 360' phase with linearity, I would suggest look at dual quadrature XOR phase comparisons. (so one is in mid scale, when the other hits the edges) ( or even more phases, 4 would be simple from 10MHz, and use 4 ADC channels - then 3 of the 4 would be low-error ) -jgArticle: 121210
John, Thanks for you input. I looked at the ADUM1401 datasheet. So you are suggesting that on the FPGA side of this device, I connect the Vdd1 to 2.5 and Gnd1 to ground but on the other side of this device I connect the Vdd2 to +1.2 and GND2 to -1.3V. Is that correct? AlbertArticle: 121211
Ben, I am not able to see your picture clearly. I think that simple bipolar npn transistor can work if the biasing is done right. I am bit concerned about the rise time if the biaising is not done right. Thanks. AlbertArticle: 121212
John H, The traget device will be running its VCC at 1.2V and Ground at -1.3V. Normally it will be running at 2.5 and 0 but in my application I need to run at +1.2V and -1.3V in order to comply with the differential electrical specification. But in doing so, the sideband control pins (SPI Bus pins) electrical changes. You asked if I can get by without ground reference I/O. Are you suggesting to connect the FPGA outputs SCLK and SERIAL DATA IN, directly to the target device? If it is just a matter of scope probing then I can get by without ground reference i/o. Thanks. AlbertArticle: 121213
Albert Nguyen wrote: > John, > > Thanks for you input. I looked at the ADUM1401 datasheet. So you are suggesting that on the FPGA side of this device, I connect the Vdd1 to 2.5 and Gnd1 to ground but on the other side of this device I connect the Vdd2 to +1.2 and GND2 to -1.3V. Is that correct? > > Albert Absolutely NOT my suggestion. You want the FPGA to interface to those odd voltages. Hook the FPGA Vcco to +1.2V and the FPGA GND signals all to -1.3V. Just perform a mental shift of all FPGA voltaqes by 1.3V *IF* there are no other I/O that must interface as system ground referenced signals. If you can make *all* I/O a 2.5V swing relative to -1.3V, everything can flow. If you have TTL signals going in one side from an external source and the +1.2/-1.3V signalling on the other side, you will need external signal translation. If your system is fully contained, there is no explicit need to make the ground reference for pushbutton-driven logic and the ground reference for the funky I/O levels of your unusual device the same potential. All I'm suggesting is a mental shift of what "ground" is for an entire device. But only if it can be applicable to the entire device.Article: 121214
"HT-Lab" <hans64@ht-lab.com> wrote in message news:x_Jgi.5846$nE2.2947@newsfe3-win.ntli.net... >> Anyway, Modelsim XE-III 6.2c starter-edition ran >> Systemverilog simulations just fine. So did Xilinx remove >> this feature from XE-III 6.2g? Nowhere in Xilinx's >> online documentation, does Xilinx claim to support >> Systemverilog. But I'd like to get a definitive/official >> answer. > ... > Do you have the sv_std folder in your installation directory? (I have it > on my PE installation). I checked my \modelsim_xe_starter dir, and the sv_std subdir is there. From what I can tell, the 6.2g installer puts the files there, but the simulator refuses to load them if the simulation contains any Systemverilog modules/submodules. Mentor's free Modelsim PE Student Edition (6.3p1) runs Systemverilog simulations just fine...though I hope there isn't some kind of weird interaction when multiple Modelsims are installed on the same PC!Article: 121215
Jim, thanks for your remarks! Because I did not want to make it too difficult I simplified my explanation a bit and left out some things that I regarded not significant for the problem: It is NOT the cpld's xor output directly that I am trying to integrate, which would be really very difficult with the intended precision. Instead this output merely drives an precision high speed diode based switch built from some HSMS-2812 which connects an summing rc-element alternating with two reference voltages that are indeed of highest quality in terms of precicion, tempco and 'clean-ness' and yes, low impedance. While this analogue circuitry has been suspected to be the source of problems it has now (where the direct comparison with the TIC based measurments was possible) turned out to work like charming. > So, do not use a CPLD as the Phase Comparitor, but use an LVC Exor gate, > preferable with Schmitt. eg LVC1G97, with analog Supply decoupling. Using an external xor will be the next thing that I am going to try. However, even this external xor will only drive the switch described above and therefore its supply will be less critical than you suggest. Because I am out for speed (10 MHz may not be the highest frequencies to compare) I ordered some 74AHC1G86 from Farnell. Do you think that the LVC part could be the better performer due to the Schmitt trigger? > You may even find, you cannot have both non-locked frequencies in the > same package, so may need separate /4 blocks This will be the next-next thing to do. Again I simplified a bit: The divide by 4 flip-flops are the things that provide symmetrical quadrature outputs. In front of them are programmable predividers that enable the circuit to compare two signals of not the same frequency. However for the experiment described these predividers were de-activated. These predividers are the reason for using the 'big' 75108. With two separate packages I will be able to use smaller cplds. > Also XOR gates will be quite good at 90' output, but will not be linear > at needle pulse phase outputs, so if you need 360' phase with linearity, > I would suggest look at dual quadrature XOR phase comparisons. > (so one is in mid scale, when the other hits the edges) Basically that is the reason for dividing by 4 but I did not mention the additional quadrature outputs. The circuit is indeed exactly as you suggest. It has an small microcontroller that looks at the voltages of two quadrature phase comparators with an LTC2402, chooses which is the more appropiate one to use and automatically corrects for the 'jump' in phase when switching between the quadrature outputs. All of this works even better than expected. It is just that the cpld which has not been suspected at all as an possible source of problems now turnes out to be the true beast. > This stuff is NOT on the chip designer's radar :) Surely not! Nor has it been on the radar of the designers of the MECL gates that HP used to build their K34-5991A linear phase comparator from! But sometimes using digital stuff for analogue purposes and vice versa can be very funny and shows that the difference is sometimes not that strict. > Any edge that is very close to another, WILL move the threshold, and > so cause phase non-linearities. Yes, from some earlier experiments I would have suspected & accepted THIS. But the error function that I tried to describe covers the COMPLETE range of phase-relationships that the two signals can have and that is what makes me wonder. If you supply an address to where I can send something I will be glad to send you an image of it. Best regards Ulrich Bangert "Jim Granville" <no.spam@designtools.maps.co.nz> schrieb im Newsbeitrag news:46839488$1@clear.net.nz... > Ulrich Bangert wrote: > > Gents, > > > > please allow me to confront you with some strange timing behaviour which I > > have measured with an Xilinx XC95108 cpld. > > > > Consider two well conditioned clock signals of 10 MHz (both having EXACTLY > > the same frequency) entering the cpld. Inside the cpld each clock signal is > > divided by 4 by means of two d-flip-flops. The two resulting 2.5 Mhz signals > > enter an exclusive-or-gate which delivers an output signal where the > > pulse/pause-relationship directly depends on the phase relationship of the > > two input clocks. > > > > If some of you feel reminded to something that you have seen before: Yes, > > basically this is the principle of an so called linear phase comparator > > which has been used to compare high stability clocks (for example cesium > > clocks) against each other before high resolution time interval counters > > like the HP5370 or the Stanford Research SR620 were available. > > > > Now imagine one of the two clocks is de-tuned by exactly 0.001 Hz. It is a > > bit beyond the discussion HOW this is achieved but you may believe me that > > this is possible and that THIS is not part of the discussed problem. Now the > > phase relationship of the clocks changes slowly in time as does the > > pulse/pause relationship behind the xor gate. The pulse/pause relationship > > of the xor's output can be measured by two completely different methods: > > > > a) by generating an dc voltage which is directly proportional to the > > pulse/pause relationship (again a bit tricky if you want it to be an really > > high resolution measurement, but it can be done) > > > > b) by directly measuring the output pulse width with an high resolution time > > interval counter like the SR620 having a 25 ps single shot resolution for > > time interval measurements. > > > > It is important to note that both methods to measure can be applied at the > > same time and that both methods (although based on completely different > > physical laws) deliver results that despite some statistical fluctuations > > are basically the same. That is why I am pretty sure that what I measure is > > really an property of the signal itself and not one of the measurement > > apparatus. > > > > If I record the pulse width over time using the two methods and display it > > graphically it looks like an pretty linear relationship at the first glance. > > If however some math is applied to make it evident how good the linear > > relationship really is met then the result is that there are fluctuations in > > the pulse width in the order of some +/-450 ps from the expected values. > > > > About these fluctuations the following facts are known: > > > > 1) They are not existent in the inputs clocks > > > > 2) Expressed in time units as well as expressed as an dc voltage the > > fluctuations are orders of magnitude bigger than the resolution and > > precision of the time/dc measurement. > > > > 3) The fluctuations are by no means of stochastical nature. Instead, If an > > positive fluctuation is noticed at an certain phase between the clock > > signals, an fluctuation of the same magnitude and sign will be noticed the > > next time when the clock signals have the same phase relationship. Or in > > other words: The pulse width is an direct function of the phase relationship > > of the clocks + an error function which is an direct function of the phase > > relationship between the clocks. > > How often do you see this, 4 or 8 times per 2.5MHz cycle ? > > > > > It seems as if the phase state of one of the signals can have an linear like > > modulating effect on the phase state of the second signal (and perhaps vice > > versa). Some of you may come to the conclusion that +/-450 ps is not an > > number to cause real world troubles but in my case: The whole arrangement > > has the intention to measure phase fluctuations of the input clocks that ARE > > REALLY THERE but that are smaller at least one order of magnitude than the > > noticed errors. And that is why +/-450 ps is an real annoying number for me. > > > > Any hint will be highly appreciated > > TIA, Ulrich Bangert > > I think I have followed this. > If you are trying to 'zoom into' the phase to high precisons, using > analog Phase integration, there are some rules to follow. > > Vcc and Gnd must be VERY clean. > That means no other clocks, and /4 is going to cause more edges and > bounce, plus Vdd impedance noise is usually quite bad on CPLDs. > Any edge that is very close to another, WILL move the threshold, and > so cause phase non-linearities. > Normally, these are so small, well under Tpd, so in the digital domain > they do not matter much. [Some CPLDs will show Tpd delta, vs outputs loded ] > > This stuff is NOT on the chip designer's radar :) > > So, do not use a CPLD as the Phase Comparitor, but use an LVC Exor gate, > preferable with Schmitt. eg LVC1G97, with analog Supply decoupling. > > You may even find, you cannot have both non-locked frequencies in the > same package, so may need separate /4 blocks > > Also XOR gates will be quite good at 90' output, but will not be linear > at needle pulse phase outputs, so if you need 360' phase with linearity, > I would suggest look at dual quadrature XOR phase comparisons. > (so one is in mid scale, when the other hits the edges) > ( or even more phases, 4 would be simple from 10MHz, and use 4 ADC > channels - then 3 of the 4 would be low-error ) > > -jg >Article: 121216
Hello,
lets take this verilog example snipplet
reg clk_en;
reg [<WIDE>:0] wide_reg;
always @(posedge clk)
begin
clk_en <= !clk_en;
wide_reg <= <some complicated action>;
end
Now synthesis expectedly finds a delay for the wide_reg a little longer then
the projected clk. I think, I am right that with toggling clk_en, I can
effectively double the time the <some complicated action> path may take
without causing problems.
How do I constrain this path in the UCF file so that ISE doesn't try to
optimize that path?
Thanks
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 121217Having FPGA VCC on 1.2V and GND on -1.3V is not possible as it affects many other FPGA signals. Thanks. AlbertArticle: 121218
gamer wrote: > My goal is to implement a bit-error counter targeting 1GHz. The > datawidth is parametrizable. I started off this way, > > Verilog code: > ---------- > assign mismatch[datawidth-1:0] = input_data ^ expected_data; > assign matched = ~( | mismatch); // reduction NOR > > always @(posedge clk or posedge reset) begin > if (reset) > error_count = 0; > else if (~matched) > for (i=0; i<datawidth; i=i+1) > error_count = error_count + mismatch[i]; > end > ---------/////////---------------------- > The above meets timing for small datawidths (like 8-bits) and starts Remember this, it is a key to a possible solution! > failing to meet timing once the datawidth gets larger. I will be glad > for suggestions of alternate ways to implement this bit-error counter. > In practice our datawidths could go upto 256 bits. You need to parallelize your error counter, particularly for very wide (256-bit?) paths: A few layers of full adders to reduce the 256 input lines into a more reasonable number, then one or more carry-save accumulators to gather these into something that can be handled very quickly. Only when reading out the number of errors do you propagate the carries to generate the final/real counts. Terje -- - <Terje.Mathisen@hda.hydro.com> "almost all programming can be viewed as an exercise in caching" From tbrown@tyzx.com Thu Jun 28 07:41:53 2007 Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!nx01.iad01.newshosting.com!newshosting.com!130.81.64.211.MISMATCH!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny06.POSTED!95dec472!not-for-mail From: Terry Brown <tbrown@tyzx.com> Subject: Re: Xilinx Modelsim XE-III 6.2g no more Systemverilog support? Newsgroups: comp.lang.verilog,comp.arch.fpga References: <h1Dgi.4487$vi5.1602@newssvr17.news.prodigy.net> User-Agent: Pan/0.125 (Potzrebie) Message-Id: <pan.2007.06.28.14.40.37@tyzx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lines: 53 Date: Thu, 28 Jun 2007 14:41:53 GMT NNTP-Posting-Host: 71.111.69.155 X-Complaints-To: abuse@verizon.net X-Trace: trndny06 1183041713 71.111.69.155 (Thu, 28 Jun 2007 10:41:53 EDT) NNTP-Posting-Date: Thu, 28 Jun 2007 10:41:53 EDT Xref: prodigy.net comp.lang.verilog:36520 comp.arch.fpga:133081 X-Received-Date: Thu, 28 Jun 2007 10:41:54 EDT (newsdbm02.news.prodigy.net) I think Mentor mistakenly thinks that further restricting their licenses will make customers purchase more expensive licenses because they can't live without Mentor products. With the upgrade from Modelsim Designer 6.1f to Modelsim 6.2f, you lose the ability to run Designer in PE mode--this without any notification, and without grandfathering in upgrades for existing paying customers at no charge. A while ago, they similarly restricted USB based key licenses so that you couldn't run multiple copies on a single machine, even if you did have valid licenses and keys. I'm going to switch to Riviera--Linux versions at reasonable pricing, nearly twice as fast as Modelsim PE, and hungry enough to actually think the customer might need real support. Terry Brown On Wed, 27 Jun 2007 17:11:55 -0700, Xilinx User wrote: > I upgraded my Modelsim XE-III 6.2c starter edition to Modelsm XE-III > 6.2g starter edition. Before isntalling the new software, I uninstalled > 6.2c (from Control Panel), and then I deleted the > \modelsim_xe_starter directory on my hard-drive. > > After the upgrade, I recycled the license.dat file from the old modelsim > starter edition. (The license checker says it's valid.) I tried running > some Systemverilog testbenches I had... all of them produce the same > fatal error. I can compile the code without problem. But when I try to > start the simulation (using the 'vsim' command from the Modelsim > command-line), I get the following error message: > > \modelsiim_xe_starter\win32xeoem/../sv_std is not compiled with XE > simulator. > > My Systemverilog testbenches have a combination of Verilog-2001 and > Systemverilog modules, but I tried a simple testcase with just a single > Systemverilog module -- same problem. This was just a simple .sv file > with an interface declaration (but no 'advanced' features that require > the Questa license.) I also compiled a simple (single-file) VHDL > testbench and (single-file) Verilog-2001 testbench. Both compiled and > simulated just fine. > > i was going to suggest buying a few XE-III (full) licenses, but that was > contingent upon, apparently, an undocumented/unofficial support for > Systemverilog. Now, I'll probably suggest getting (Mentor) Modelsim-PE. > > Anyway, Modelsim XE-III 6.2c starter-edition ran Systemverilog > simulations just fine. So did Xilinx remove this feature from XE-III > 6.2g? Nowhere in Xilinx's online documentation, does Xilinx claim to > support Systemverilog. But I'd like to get a definitive/official > answer.Article: 121219
I'm looking at adding an embedded USB JTAG programmer onto our latest board, and am just looking for a bit of advice. The board has on it an Spartan 3, and an XCF08P Platform Flash prom, the main processor on the board is a Compulab computer on module. We need to be able to program the flash in system using the Compulab CoM. We currently do this using the LPC interface on the CoM, and an extra CPLD, using the xilinx JDrive software. Currently doing an erase, program, and verify of the XCF08P takes ~60 seconds. I was thinking it might be a nicer solution to use a USB device like the FTDI 2232 to give us JTAG access, but would like a bit of advice as to how easy it is to use these things, and is the programming time likely to be any quicker. Neill.Article: 121220
On 28 Jun., 15:40, Terje Mathisen <terje.mathi...@hda.hydro.com> wrote: > A few layers of full adders to reduce the 256 input lines into a more > reasonable number, then one or more carry-save accumulators to gather > these into something that can be handled very quickly. > > Only when reading out the number of errors do you propagate the carries > to generate the final/real counts. In Virtex-5 the 6-LUTs point to a 6-to-3 reduction instead of full adders. You can also use BRAMs for an 11 to 4 reduction. 512 bits at 500MHz might be easier than 256 bits at 1GHz. Kolja SulimmaArticle: 121221
On Jun 28, 9:34 am, Uwe Bonnes <b...@hertz.ikp.physik.tu-darmstadt.de>
wrote:
> Hello,
>
> lets take this verilog example snipplet
>
> reg clk_en;
> reg [<WIDE>:0] wide_reg;
>
> always @(posedge clk)
> begin
> clk_en <= !clk_en;
> wide_reg <= <some complicated action>;
> end
>
> Now synthesis expectedly finds a delay for the wide_reg a little longer then
> the projected clk. I think, I am right that with toggling clk_en, I can
> effectively double the time the <some complicated action> path may take
> without causing problems.
>
> How do I constrain this path in the UCF file so that ISE doesn't try to
> optimize that path?
>
> Thanks
>
> --
> Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
I'm assuming you mean:
always @(posedge clk)
begin
clk_en <= !clk_en;
if (clk_en) wide_reg <= <some complicated action>;
end
You can define groups of flip-flops whose clock enable is clk_en
like:
NET "clk_en" TNM_NET=FFS(*) CKEN_FFGRP;
Then use FROM .. TO timing constraints or TIG constraints on the
grouped elements.
TIMESPEC "TS_CKEN"=FROM "CKEN_FFGRP" TO "CKEN_FFGRP" TS_CLKPERIOD*2;
These examples are based on the 6.1i constraints guide, so if you
are using a newer version you should refer to the latest constraints
guide.
HTH,
Gabor
Article: 121222<Albert Nguyen> wrote in message news:eea7b1c.7@webx.sUN8CHnE... > Having FPGA VCC on 1.2V and GND on -1.3V is not possible as it affects > many other FPGA signals. > > Thanks. > > Albert Then you absolutely need level translators. I feel I lost you on the idea of shifting your rails to a different absolute voltage while keeping all the rails and signals properly specified relative to each other. It may be your system doesn't need the absolute voltages you're planning. Since I don't know enough about your system to see if a compromise can be made, just design level translators. You might look at using PNP transistors with a pull-down to -1.3V to provide the +1.2V to -1.3V swing.Article: 121223
On 28 Giu, 16:49, nei...@pipstechnology.co.uk wrote: > I'm looking at adding an embedded USB JTAG programmer onto our latest > board, and am just looking for a bit of advice. The board has on it > an Spartan 3, and an XCF08P Platform Flash prom, the main processor on > the board is a Compulab computer on module. We need to be able to > program the flash in system using the Compulab CoM. We currently do > this using the LPC interface on the CoM, and an extra CPLD, using the > xilinx JDrive software. Currently doing an erase, program, and verify > of the XCF08P takes ~60 seconds. I was thinking it might be a nicer > solution to use a USB device like the FTDI 2232 to give us JTAG > access, but would like a bit of advice as to how easy it is to use > these things, and is the programming time likely to be any quicker. > > Neill. Hi, I added support for the FTDI2232 chip to Jamplayer (from Altera). With this tool you can program both Altera and Xilinx device. The input file is in STAPL format, you can generate it with ISE. I tested the FTDI2232 version with Altera device (Stratix and EPC configuration device). I tested another porting of Jamplayer (using GPIOs from an ARM9) with XC9500 series. I can send you the FTDI2232 version. I don't know the programming time with XCF08P. MatteoArticle: 121224
The 'b1', 'b2', etc. on the gates are the number of inverted inputs. Got to the help topics for software help, or software manuals (libraries guide) for information on the available gates. Expand 'Generate Program FIle' and double click 'Configure Device' The Program iMPACT will start. It will sometimes attempt to find the programming cable and identify the devices in the JTAG chain. If the cable or board is not connected it will generate and error. iMPACT is used to download all Xilinx devices using JTAG. You can download supported proms, cpld, and fpga devices. Go to 'Help/Help Topics' to learn about iMPACT. Schematic was originally the only way to design with Xilinx tool upto version 4.2. Then VHDL/VERILOG became available for developing large designs. Schematic design, using gate primitive is useful only for small designs. It is still available mostly for top level block design and viewing schematics of synthesized VHDL/VERILOG code.
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