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
"Jozsef" <bit_vector@tvn.hu> wrote in message news:1155153571.322179.241290@75g2000cwc.googlegroups.com... > PQFP208... and inspected with microscope, no short circuit or floating > pins found.... Have you tried a different pin? Have you checked all the FPGA voltages? /MikhailArticle: 106251
"Alex Iliev" <iliev@nimbus.dartmouth.edu> wrote in message news:pan.2006.08.09.20.14.10.432160@nimbus.dartmouth.edu... > > Also, the LEDs have a register in front of them. In which of the 2 FPGA's? It's not in your code, and you previously said that the second FPGA is configured to pass the data straight through... Or do you mean it is a separate IC? In any case if it is really a register and not a buffer then you certainly need to clock your data in it somehow... So make sure it gets the clock. /MikhailArticle: 106252
Antti wrote: > Hi Bart, > > should Lattice do more? The answer is YES. > Hi Antti, thanks for the ideas. i forwarded them onto the folks at Lattice who work on that. that's one of the main concepts behind our new blog, getting direct connection to senior engineers at Lattice and starting a conversations with them. if you haven't checked the blog out yet, here is the link: http://latticeblogs.typepad.com/ rgds, bartArticle: 106253
Just a slight correction: The theoretically lowest clock recovery sample frequency is 3 times the bit frequency (not 4 times). You simply start a digital differentiator on any level transition, and make that differentiator ignore level transitions for the two following periods, in order to not trigger again. That recovers the clock, and the rest is trivial. Since there is a 1/3 bit time uncertainty, this scheme works theoretically (best-case) with at least three clocks per bit cell. Obviously, a practical implementation should add some guardband, but 4x should be reliable if the frequencies are stable and there is not too much jitter in the system. Of course, 6 or 8 times is even more robust. Peter Alfke., Xilinx ================ rickman wrote: > Antti wrote: > > Michael Dreschmann schrieb: > > > > > Hi all, > > > > > > we are trying to implement a 100 MBit communication link witch uses > > > manchester coding. The signal is generated by a CPLD (xc2c64a) and we > > > hope we can receive it with an FPGA (Virtex4 for example). > > > Because the CPLD design will work at 2.5V and should use minimal power > > > (sensor node) my question is if it is possible to use a crystal with a > > > NOT-gate in the CPLD for generating the oszillator frequency instead > > > of an external oszillator. > > > The second question concerns the reception of the datastream within > > > the FPGA. My thought was to use a digital pll as mentioned here > > > http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/dpll.html > > > to generate a sample clock for the incomming bitstream. > > > With the help of a DCM module I would generate two 300 MHz clocks, one > > > shifted by 180 degree. Then I should be able to sample the incomming > > > stream with 600 MHz and I hope this is enough to stay phase locked > > > with the datastream. But I haven't done such a fast communication > > > before, so I've no idea if this will work. Any comments from you would > > > be nice. > > > > > > Thanks, > > > Michael > > > > you can look at the USB DPLL get the sub phy from opencores as example > > it uses 4x clock to deliver mid-bit clock enable to latch the data. > > something > > similar should work for manchester as well. > > > > cpld oscillator shure work, but you still need a resistor across not > > gate in-out > > it want oscillate otherwise. I have spent some time trying to get an > > crystal > > to swing on FPGA pins without external resistor but have not yet > > succeeded. > > I am not familiar with USB data recovery designs, but I have worked > with Manchester encoding before. A 4x clock is on the hairy edge for > data recovery. The way Manchester encoding works, you start the bit in > the opposite state and transition to the correct state in the middle of > the bit. You can also see a transision at the start of a bit if it > matches the previous bit. To sample the data you have only one half a > bit time. You have to have a lockout period to prevent a false edge > detection on the edge between bit cells. > > Since you have a one clock cycle uncertainty in the timing of the > detection, you have trouble timing the length of the lockout period for > detecting the edge in the next middle of bit cell. At 4x any timing > error will result in eventual slips in timing. You need assure that > you clock just a bit faster than 4x to never have the edge detector > locked out when in the center of a bit cell. > > The logic of a Manchester encoder or decoder is simple. But you have > to be careful to sample fast enough to make it work. A 4x clock will > not work reliably. A 4.1x clock will.Article: 106254
I have the following code which errors in 8.1.3 sw :
the error is something like ..actual value associated with a generic must be
a globally static..
coef_2_rams : for i in 0 to 17 generate -- bit
attribute RAM_INIT of inst : label is coef_init_2(i);
begin
inst: RAMD_OPREG
generic map (
RAM_INIT => inst'RAM_INIT
)
port map (
WADDR(3 downto 2) => "00",
WADDR(1 downto 0) => etc
this is the logic being instantiated :
a_core : if true generate
attribute INIT of ramd : label is RAM_INIT;
begin
ramd : RAM16X1D
generic map (
INIT => str2suv(ramd'INIT) <<<< here is the problem
)
port map (
a0 => WADDR(0),
a1 => WADDR(1),
a2 => WADDR(2),
a3 => WADDR(3),
str2suv is a function to convert a string to a logic_vector. This works if I
do INIT => str2suv(RAM_INIT)
The problem looks to be the ramd'INIT I think.
The reason for doing this is to get a synthesis attibute and a generic for
simulation without the error prone typing the value twice. The code compiles
under Mentor Precision - and needs to keep doing so. Any ideas ?
The only solution I can think of it to have both :
attribute RAM_INIT of inst : label is coef_init_2(i)
*** and ***
RAM_INIT => coef_init_2(i)
Thanks for any ideas - and if XST people are reading this, any idea when
this feature will be included ?? I have a very large number of these to
change otherwise ...
/MikeJ
Article: 106255Just plug it into the wall. The PROM comes preloaded with demo code that makes the blinkylights and countynumbers. (At least, the one I got last week does...) -Matt "Phil Tomson" <ptkwt@aracnet.com> wrote in message news:ebbn9h019ci@enews1.newsguy.com... > > I've got ISE 8.1 running under Linux (Gentoo, 2.6.15 kernel, amd64 - I > plan to use the xc3sprog program to send the bitsream to the board) and > now I'd like to hook up the starter kit board and try it out... > I'd like a simple design that I could run through ISE and download to the > board that would do something on the LEDs so I know things are working, > but I don't see anything like that - according to the README for xc3sprog > there is some design called echo_out that does something like this, but I > can't find it anywhere. Is it (or something similar) available on the web > anywhere? > > ...maybe I'm missing something, but it seems like something like this > should be in the Sparten-3 Starter-kit Board User Guide. One of the first > things they should have you do is download a test design and run it > through ISE and download the bitstream to the FPGA at which point it would > display something on the LEDs in order to make sure you've hooked up > everything correctly and that you've setup ISE correctly. > > PhilArticle: 106256
In comp.arch Rob Thorpe <robert.thorpe@antenova.com> wrote: > > I think you're probably right. It is difficult to introduce > instructions useful to Lisp in such a way that they:- > * Don't make the machine harder to design, or make it slower > * Don't fix the idea of how certain lisp idioms should be implemented > > But still I'd be interested to see what people come up with. The > pitfall H & P describe is that of designing an instruction set in a > high-level manner, which is not the subject of the discussion. It may > be possible to make a microprocessor more lisp-friendly by doing a lot > less than this. I think it depends a lot on what model you have in mind for the implementation - are you trying to make it fast for a bytecode interpreter, jit or compiled lisp? And once you pick a flavour (or several) it makes sense to see that other languages that get processed in a similar way (scheme, java, python, perl, ...) get a speed-up too. For example, you can easily spend way too much time on modern machine in doing slow string hashes and string compares for symbol lookup (ok, not just symbol lookup). You can also speed up dynamic table lookups. And of course, then there are tagged pointers... Which I think can be made beneficial and OoO friendly and C-neutral and not dertimental to performace in any way. Which of course means you have to treat them in a totaly RISC-y, the code knows what its doing, and not do things like harware tag checks on load / store / jump. -- Sander +++ Out of cheese error +++Article: 106257
On 2006-08-08 12:57:46 -0700, Bob Perlman <bobsrefusebin@hotmail.com> said: > On Tue, 8 Aug 2006 10:37:46 -0700, "Eric Crabill" > <eric.crabill@xilinx.com> wrote: > >> Philip Freidin is one who has achieved the final goal on this particular >> path and is a guiding light to the student walking the path. On a material >> level, he is someone like Michelangelo for an artist. > > I agree completely. And the ceiling in his office is spectacular. As one of those people Philip has helped, I would like to nominate him too. Clear, concise explanations, just perfect when you're struggling to understand something. Ray A. gets an honorable mention as well (he makes you think more [grin] - which is good in the long run :-) SimonArticle: 106258
Hi all, So, before I splash out on the EDK, I'd really appreciate some advice on what the real MHz limits are on the microblaze (almost certainly in a Spartan-3E). From the webpage it says it'll do 100MHz but then qualifies it as execution from BRAM only. Questions... - Does the 100 MHz figure imply a 100 MHz bus-speed too ? I see a bunch of tutorials where the bus is only 66MHz. - How does the system scale as you add more PLB peripherals, or OPB ones for that matter - If I make a peripheral, do I get bus-mastering built-in (or at least supported) with the tools provided ? It would be useful for more than one peripheral to access the SDRAM controller, for example :-) - If I can persuade myself to splash the cash on a V4FX design instead, what sort of real-world MHz am I looking at for the PPC chip ? Again, it claims 450MHz in the datasheets, but is that realistic ? Since this is only a hobby, $500 is a large chunk of pocket-change so I'd be very grateful for answers to the above. If (as I've been told) it's typically "difficult" to get 100MHz from a microblaze (with h/w multiplier, barrel shifter, SDRAM interface, and a couple of peripherals), I may look at using the FPGA to interface with an external coldfire at 147MHz instead, and then I might not need the EDK, though unit costs of the board will be more expensive... Thanks in advance, SimonArticle: 106259
Peter Alfke wrote: > Just a slight correction: The theoretically lowest clock recovery > sample frequency is 3 times the bit frequency (not 4 times). > You simply start a digital differentiator on any level transition, and > make that differentiator ignore level transitions for the two following > periods, in order to not trigger again. That recovers the clock, and > the rest is trivial. > Since there is a 1/3 bit time uncertainty, this scheme works > theoretically (best-case) with at least three clocks per bit cell. > Obviously, a practical implementation should add some guardband, but 4x > should be reliable if the frequencies are stable and there is not too > much jitter in the system. Of course, 6 or 8 times is even more robust. I don't agree. By ignoring the signal for 2 clock edges, you are actually delaying by up to 3 clock edges. You may have just missed catching the transition on edge 1, then you wait until edge 2 and 3. So the jitter in the measurement will put you (worst case) right at the next transition on your input signal and you may just miss that. If all clocks were perfect and there was no worry about transition timing on the edges, etc, then yes, I would agree you could do it with 3 clocks. But in the real world with imperfect clocks and signals you can miss an edge when the timing is boarderline. The same issue prevents you from working properly with 4 clocks because by waiting 2 clock edges you can improperly "see" the transition between cells and by waiting 3 clock edges you can miss a valid transition just as above. With 5 clock cycles to a data bit, you will be able to wait 3 clock edges and will always be assured of ignoring the interbit transition and "seeing" the mid-bit transition. 3/5 of a bit to 4/5 of a bit delay is always in the first half of the next bit to within 10% of the bit period or 1/2 a clock cycle. Not many systems will have that much jitter or timing distortion. As to how much jitter is tolerable, I think this comes down to your metastability figures. I don't recall the exact number, but I believe it is the neighborhood of low 10's of ps. I have never worked with a system where the clock was that accurate or stable and the signals were reproduced that accurately. Heck, just a couple of extra pF on a signal line can skew the edges enough to add 100 ps of jitter and screw up a 3x or 4x clocked decoder. I guess you could go to a fractional ratio between the clock and the data. At 3.5x waiting 2 edges will give you 2 to 3 clocks delay which is 0.25 of a clock beyond the inter-bit transition to be ignored and 0.5 clock cycles before the next mid-bit transition. It is just the cases that are trying to be integer multiples of the bit rate that are problematic until you get to 5x. There really is no reason to run at integer multiples since you can never match the frequency exactly. So even 4.1x will give you enough margin unless the skew and jitter is pretty bad which can happen depending on the transmission medium.Article: 106260
rickman wrote:
> I don't agree. By ignoring the signal for 2 clock edges, you are
> actually delaying by up to 3 clock edges. You may have just missed
> catching the transition on edge 1, then you wait until edge 2 and 3.
> So the jitter in the measurement will put you (worst case) right at the
> next transition on your input signal and you may just miss that. If
> all clocks were perfect and there was no worry about transition timing
> on the edges, etc, then yes, I would agree you could do it with 3
> clocks. But in the real world with imperfect clocks and signals you
> can miss an edge when the timing is [borderline].
<snip>
While the specific approach about a digital differentiator and looking
at specific samples relative to an input stream ignored by a few cycles
may be confusing, if you don't wait to acquire the signals but analyze
what you got, the concept flows.
_____
If you can find a sampling such that you can guarantee at least one
unambiguous sample in any half bit period - including jitter - then you
can recover the data. The worst case for the 3x clock is when one clock
samples midpoint of one half-bit section of the data leasing the front
and back edges of the next half bit perilously close the the edges.
(view in fixed space font:)
__ _____ __
__/ \_____/__
Sample Points ^ ^ ^ ^
Depending on the jitter it might not work but the sample points are 1/12
of a full bit period from the data transition. If one of the sample
points is on the hairy edge, the value *will* stabilize through standard
handling of asynchronous signals.
The minimum sampling frequency for guaranteed operation is determined by
the minimum pulse width (less than half a bit period) degraded by the
jitter of the edges (both leading and trailing) as well as jitter in the
sampling clock. The DCMs may produce a large amount of (calculated)
jitter that would be included in any DCM-based sampling clock analysis.
But for a 100 MB/s data rate, the 5 ns period won't be degraded *that*
much. While 300 MHz should work flawlessly, even a 250 MHz sampling
clock might work if the duty cycle is well controlled. 5 ns half
period, 750 ps pk-to-pk jitter, at least one of the sample points 4 ns
apart should hit the meat of the half period. Fractional multipliers
are just such a bother.
Metastability windows are now sub-picosecond so all that needs to be
worried about is standard synchronization for those one in a million
events that happen once every 5 seconds at 2x 100 MB/s.
Sample everything, let the logic figure it out.
The clock is extracted from the data rather than the data extracted from
the clock.
There's even a Xilinx app note that describes how to extract data from
wide busses above 600 MB/s without rocket I/O. There's no 1.5x clock
available at those rates!
Article: 106261HI, I am sorry I am running Mig 1.5 was a typo. Right now iam encountering two problems: If i post a sequence of reads to the read fifo, the first one always fails than I have several succesful reads. I posted 256 writes and sucessive reads and they were all succesfull besides the first one. Strangely inl in a really long succesive write then read out sequence (1k read ops) the first 100 are not succesfull and then I get 256 succesful read outs and the again errors for the remaining ones. Often the read out values are almost correct like only some 2-3 bits different.. > If these values never change, then you don't have the same problem that > I did. But then again I hardcoded the observed (static) values and NOTHING worked anymore. Idont know if I can trust chipscope. How did you decide to hardcode the values? Are the rising and falling clk_count connected in some way like if one is reg3 teh other one is also reg3? heiner Joseph Samson schrieb: > heinerlitz@gmx.de wrote: > >> > >>I observed clk_count_rise and clk_count_fall using chipscope and found > >>out that they never change which means they are defacto hardcoded. The > >>delay is hence always the same even without hardcoding the value. > > If these values never change, then you don't have the same problem that > I did. I think your only hope now is to use Chipscope to track down the > failure, triggering on the error signal and trying to figure out what > causes it. > > You say that you're running MIG 1.6, but the Xilinx site only shows MIG > 1.5. Did it come with ISE8.2i? > > --- > Joe Samson > Pixel VelocityArticle: 106262
Yes, I've tried different pin, but nothing. All supply voltage is in the operating ranges. In this case, there are two boards which shows these simptoms... :S I've taken a look on PAR simulation modell, but it seems to be correct. Simulation is not equal with real physic world as I've observed in some cases. But a simple counter isn't work in real world, and works on simulation? This is my great challange to solve... now. Jozsef MM wrote: > "Jozsef" <bit_vector@tvn.hu> wrote in message > news:1155153571.322179.241290@75g2000cwc.googlegroups.com... > > PQFP208... and inspected with microscope, no short circuit or floating > > pins found.... > > Have you tried a different pin? Have you checked all the FPGA voltages? > > > /MikhailArticle: 106263
I have two clocks which are relatively synchronous (ie. the frequencies are exactly the same because the originate from the same master clock), but one of the clocks is shifted in phase, and this phase shift is dynamically variable and may be up to one whole period. I need to switch between these two clocks, but without losing rising edges. From my experiments with BUFGMUXs, I appear to be losing a rising edge (post PAR timing simulation). I believe Peter's circuit in his Six Easy Pieces may also cause an edge to be lost. Peter writes "Any clock-switching starts when the originally selected clock goes Low, and the Output Clock then stays Low until the newly selected clock has first gone Low and then High again." I realize that asynchronous clock multiplexing has been covered many times in the group, but I simply can't find a good solution to my specific problem. Peter.Article: 106264
Check the the PAD report. Is the signal really routed to the pin that you specified in the UCF? Are all pins using the correct logic family? Kolja Sulimma Jozsef schrieb: > Yes, I've tried different pin, but nothing. All supply voltage is in > the operating ranges. > In this case, there are two boards which shows these simptoms... :S > I've taken a look on PAR simulation modell, but it seems to be correct. > Simulation is not equal with real physic world as I've observed in some > cases. But a simple counter isn't work in real world, and works on > simulation? This is my great challange to solve... now. > > Jozsef > > > MM wrote: > >>"Jozsef" <bit_vector@tvn.hu> wrote in message >>news:1155153571.322179.241290@75g2000cwc.googlegroups.com... >> >>>PQFP208... and inspected with microscope, no short circuit or floating >>>pins found.... >> >>Have you tried a different pin? Have you checked all the FPGA voltages? >> >> >>/Mikhail > >Article: 106265
Simon Gornall schrieb: > Hi all, > > So, before I splash out on the EDK, I'd really appreciate some advice > on what the real MHz limits are on the microblaze (almost certainly in > a Spartan-3E). From the webpage it says it'll do 100MHz but then > qualifies it as execution from BRAM only. Questions... > > - Does the 100 MHz figure imply a 100 MHz bus-speed too ? I see a > bunch of tutorials where the bus is only 66MHz. > > - How does the system scale as you add more PLB peripherals, or OPB > ones for that matter > > - If I make a peripheral, do I get bus-mastering built-in (or at least > supported) with the tools provided ? It would be useful for more than > one peripheral to access the SDRAM controller, for example :-) > > - If I can persuade myself to splash the cash on a V4FX design > instead, what sort of real-world MHz am I looking at for the PPC chip ? > Again, it claims 450MHz in the datasheets, but is that realistic ? > > > Since this is only a hobby, $500 is a large chunk of pocket-change so > I'd be very grateful for answers to the above. If (as I've been told) > it's typically "difficult" to get 100MHz from a microblaze (with h/w > multiplier, barrel shifter, SDRAM interface, and a couple of > peripherals), I may look at using the FPGA to interface with an > external coldfire at 147MHz instead, and then I might not need the EDK, > though unit costs of the board will be more expensive... > > Thanks in advance, > > Simon Hi Simon, 67(or 75) are most suitable candidates for the system and bus clocks. ML40x board reference designs from Xilinx that include a big bunch of peripherals are supposed to run at sysclock 100MHz but it may take an eternity in place and route. So 75MHz way more easy to obtain. MicroBlaze 5 may get little fmax performance but I havent yet real comparison values. Adding more peripherals makes it harder to meet timing, so system fmax goes lower in generic. As of multiply access to SDRAM it may be easier to add your peripherals not to the PLB/OPB bus but to the XCL ports of the multichannel SDRAM controller. So the high speed access is streamed directly to SDRAM controller. The claims for microblaze and ppc fmax have to be read with some precaution. In April 2006 Xilinx claimed 200MHz fmax for MicroBlaze 4 in Virtex-4. Maybe it is possible under some conditions but for me it sounds like wishfull thinking. Well I bet MB 5 in Virtex5 in "ultracontroller" like setup may run at 200MHz - this is more realistic. But some small medium MB.4 system in Virtex-4 does not reach 200MHz (at least with current XST synthesis, maybe XST will improve timing once again and get better performance). Similarly the 450MHz PPC operation defenetly means operation from onchip caches only with no bus peripherals at all. So for real applications you better calculate with 300MHz cpu clock. But - the type of hardcore CPU in Virtex-5FX is not yet known. It is not the same core that is in v2pro-v4, so what we can expect there is to be seen. AnttiArticle: 106266
Thanks Nico, I thought the ngc2edif tool might come into it somewhere, but how exactly do I end up with a VHDL file? Cheers, Robin Nico Coesel wrote: > "Robin Bruce" <robin.bruce@gmail.com> wrote: > > >Hiya group, > > > >I've got a design that is contained within a single VHDL file. It > >instantiates a component that is in an NGC format, so I have two files > >in my ISE project, one VHDL and one NGC. What I would like to be able > >to do is synthesise both to a single NGC by passing through the logical > >synthesis stage in ISE (XST). I'd like to get the estimated combined > >resource use and clock rate this way, and have a single logical netlist > >for the design to export it. Is there any easy way to do this? > > > >== tin-foil hat on == > >Is there anyway to return to VHDL from the NGC stage (even via EDIF)? > >== tin-foil hat off == > > There is an ngc2edif tool shipped with ISE. I think I've walked this > route once to turn an ngc into a vhdl file. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106267
PeterC wrote: > I have two clocks which are relatively synchronous (ie. the frequencies > are exactly the same because the originate from the same master clock), > but one of the clocks is shifted in phase, and this phase shift is > dynamically variable and may be up to one whole period. > > I need to switch between these two clocks, but without losing rising > edges. From my experiments with BUFGMUXs, I appear to be losing a > rising edge (post PAR timing simulation). > > I believe Peter's circuit in his Six Easy Pieces may also cause an edge > to be lost. Peter writes "Any clock-switching starts when the > originally selected clock goes Low, and the Output Clock then stays Low > until the newly selected clock has first gone Low and then High again." > > I realize that asynchronous clock multiplexing has been covered many > times in the group, but I simply can't find a good solution to my > specific problem. > > Peter. A very simplistic method to capture phase is the old type 1 phase detector; feed the clocks to a XOR - the output pulse is proportional to the phase between the clocks. This assumes you have something that can measure it. Alternatively, should you need to know the edge phase for a rising edge, use a 2 input AND gate, for a falling edge a 2-input NOR (to garner a high for each condition). (My preferred fix for synchronised but unknown or unknowable phase between the clocks for data is a FIFO, with the output delayed by 1 or 2 clocks. As your phase could be a whole period, I'd use 2 clocks.) I know you said you need to switch between the two clocks - so I'd think about using phase detection as noted above. There are very simple and effective phase detectors available (see the type 2 as well). Cheers PeteSArticle: 106268
PeteS wrote: > PeterC wrote: > > I have two clocks which are relatively synchronous (ie. the frequencies > > are exactly the same because the originate from the same master clock), > > but one of the clocks is shifted in phase, and this phase shift is > > dynamically variable and may be up to one whole period. > > > > I need to switch between these two clocks, but without losing rising > > edges. From my experiments with BUFGMUXs, I appear to be losing a > > rising edge (post PAR timing simulation). > > > > I believe Peter's circuit in his Six Easy Pieces may also cause an edge > > to be lost. Peter writes "Any clock-switching starts when the > > originally selected clock goes Low, and the Output Clock then stays Low > > until the newly selected clock has first gone Low and then High again." > > > > I realize that asynchronous clock multiplexing has been covered many > > times in the group, but I simply can't find a good solution to my > > specific problem. > > > > Peter. > > A very simplistic method to capture phase is the old type 1 phase > detector; feed the clocks to a XOR - the output pulse is proportional > to the phase between the clocks. This assumes you have something that > can measure it. > > Alternatively, should you need to know the edge phase for a rising > edge, use a 2 input AND gate, for a falling edge a 2-input NOR (to > garner a high for each condition). > > (My preferred fix for synchronised but unknown or unknowable phase > between the clocks for data is a FIFO, with the output delayed by 1 or > 2 clocks. As your phase could be a whole period, I'd use 2 clocks.) > > I know you said you need to switch between the two clocks - so I'd > think about using phase detection as noted above. There are very simple > and effective phase detectors available (see the type 2 as well). > > Cheers > > PeteS Further to this, a trick I used many years ago (using discrete parts too!) was to ensure that the phase between the clocks was between 90 and 270. To do this you need at least a 4x clock somewhere to measure the actual phase difference. If the phase pulse is too short or too long, simply invert the currently inactive clock. Cheers PeteSArticle: 106269
Hi Antti, which speed-grades are you talking about? Slowest or fastest? Thomas "Antti" <Antti.Lukats@xilant.com> schrieb im Newsbeitrag news:1155195172.444581.319200@i3g2000cwc.googlegroups.com... > Simon Gornall schrieb: > >> Hi all, >> >> So, before I splash out on the EDK, I'd really appreciate some advice >> on what the real MHz limits are on the microblaze (almost certainly in >> a Spartan-3E). From the webpage it says it'll do 100MHz but then >> qualifies it as execution from BRAM only. Questions... >> >> - Does the 100 MHz figure imply a 100 MHz bus-speed too ? I see a >> bunch of tutorials where the bus is only 66MHz. >> >> - How does the system scale as you add more PLB peripherals, or OPB >> ones for that matter >> >> - If I make a peripheral, do I get bus-mastering built-in (or at least >> supported) with the tools provided ? It would be useful for more than >> one peripheral to access the SDRAM controller, for example :-) >> >> - If I can persuade myself to splash the cash on a V4FX design >> instead, what sort of real-world MHz am I looking at for the PPC chip ? >> Again, it claims 450MHz in the datasheets, but is that realistic ? >> >> >> Since this is only a hobby, $500 is a large chunk of pocket-change so >> I'd be very grateful for answers to the above. If (as I've been told) >> it's typically "difficult" to get 100MHz from a microblaze (with h/w >> multiplier, barrel shifter, SDRAM interface, and a couple of >> peripherals), I may look at using the FPGA to interface with an >> external coldfire at 147MHz instead, and then I might not need the EDK, >> though unit costs of the board will be more expensive... >> >> Thanks in advance, >> >> Simon > > Hi Simon, > > 67(or 75) are most suitable candidates for the system and bus clocks. > ML40x board reference designs from Xilinx that include a big bunch > of peripherals are supposed to run at sysclock 100MHz but it may take > an eternity in place and route. So 75MHz way more easy to obtain. > > MicroBlaze 5 may get little fmax performance but I havent yet real > comparison values. > > Adding more peripherals makes it harder to meet timing, so system > fmax goes lower in generic. > > As of multiply access to SDRAM it may be easier to add your peripherals > not to the PLB/OPB bus but to the XCL ports of the multichannel SDRAM > controller. So the high speed access is streamed directly to SDRAM > controller. > > The claims for microblaze and ppc fmax have to be read with some > precaution. In April 2006 Xilinx claimed 200MHz fmax for MicroBlaze 4 > in Virtex-4. Maybe it is possible under some conditions but for me it > sounds like wishfull thinking. Well I bet MB 5 in Virtex5 in > "ultracontroller" like setup may run at 200MHz - this is more > realistic. But some small medium MB.4 system in Virtex-4 does not reach > 200MHz (at least with current XST synthesis, maybe XST will improve > timing once again and get better performance). Similarly the 450MHz PPC > operation defenetly means operation from onchip caches only with no bus > peripherals at all. So for real applications you better calculate with > 300MHz cpu clock. > > But - the type of hardcore CPU in Virtex-5FX is not yet known. It is > not the same core that is in v2pro-v4, so what we can expect there is > to be seen. > > Antti >Article: 106270
On Wed, 09 Aug 2006 22:40:27 GMT, "MikeJ" <mikej@fpgaarcade.nospam.com> wrote: >the error is something like ..actual value associated with a generic must be >a globally static.. > a_core : if true generate >attribute INIT of ramd : label is RAM_INIT; >begin > ramd : RAM16X1D > generic map ( > INIT => str2suv(ramd'INIT) <<<< here is the problem Presumably this is the architecture for RAMD_OPREG, and RAM_INIT is a generic in RAMD_OPREG's entity declaration? If so, then it does look like XST has got this wrong. For the actual to be globally static - 1 - str2suv must be pure; XST presumably agrees that it is pure, since it allows: >str2suv is a function to convert a string to a logic_vector. This works if I >do INIT => str2suv(RAM_INIT) 2 - ramd'INIT must also be globally static, which it is if INIT is a user-defined attribute and its value is the RAM_INIT generic. My guess is that XST is assuming that a function call actual which is the value of a user-defined attribute is never globally static. It should be straightforward to generate a test case for this. Your code looks overly complicated to me, but perhaps I haven't understood it. My own work-around would be: 1 - change > attribute RAM_INIT of inst : label is coef_init_2(i); to attribute NEW_RAM_INIT of inst : label is str2suv(coef_init_2(i)); (or just get coef_init_2 to return the required type) 2 - pass inst'NEW_RAM_INIT as the value of the generic, and 3 - pass the new generic directly as the value of INIT to RAM16X1D HTH - EvanArticle: 106271
I would check (at least) two things,
1. If the board finishes the configuration process gracefully, I mean
DONE goes high, start-up clock need to be matched with your config type
(jtagclk or cclk or userclk) mode pins are set correctly.
2. please make sure all your power supplies are OK, and VCCIO are
applied for the IO bank used.
Aurash
Kolja Sulimma wrote:
>Check the the PAD report.
>Is the signal really routed to the pin that you specified in the UCF?
>Are all pins using the correct logic family?
>
>Kolja Sulimma
>
>Jozsef schrieb:
>
>
>>Yes, I've tried different pin, but nothing. All supply voltage is in
>>the operating ranges.
>>In this case, there are two boards which shows these simptoms... :S
>>I've taken a look on PAR simulation modell, but it seems to be correct.
>>Simulation is not equal with real physic world as I've observed in some
>>cases. But a simple counter isn't work in real world, and works on
>>simulation? This is my great challange to solve... now.
>>
>>Jozsef
>>
>>
>>MM wrote:
>>
>>
>>
>>>"Jozsef" <bit_vector@tvn.hu> wrote in message
>>>news:1155153571.322179.241290@75g2000cwc.googlegroups.com...
>>>
>>>
>>>
>>>>PQFP208... and inspected with microscope, no short circuit or floating
>>>>pins found....
>>>>
>>>>
>>>Have you tried a different pin? Have you checked all the FPGA voltages?
>>>
>>>
>>>/Mikhail
>>>
>>>
>>
>>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 106272"PeterC" <peter@geckoaudio.com> wrote in message news:1155193653.437411.172220@i3g2000cwc.googlegroups.com... > > I have two clocks which are relatively synchronous (ie. the frequencies > are exactly the same because the originate from the same master clock), > but one of the clocks is shifted in phase, and this phase shift is > dynamically variable and may be up to one whole period. > Given that, the two should be treated as if they are completely asynchronous. . > I need to switch between these two clocks, but without losing rising > edges. From my experiments with BUFGMUXs, I appear to be losing a > rising edge (post PAR timing simulation). > You may have a very good reason, but why can you not afford to lose an edge? When circumstances allow you should always try to switch clocks at a time when there is 'nothing going on' in either clock domain. Are you sure that in your application that the clock switching could really be occurring at a time when stuff is still happening in both clock domains that you don't want to miss? It might very well be that you really can't afford to lose an edge in your application, but it's a key question that affects how 'simple' or 'complicated' the design solution is going to be so it's worth double checking. > I realize that asynchronous clock multiplexing has been covered many > times in the group, but I simply can't find a good solution to my > specific problem. > What resources are at your disposal? The traditional approach to moving from one clock domain to another would be simply through the use of dual clock FIFOs. Are there any dual clock memories primitives and spare logic available for use? If so, then plop down an lpm_fifo_dc (I think that's the correct name for the LPM dual clock FIFO) on each clock path and select between the two on the output side, holding the unselected path in reset. KJArticle: 106273
Hi all, I am building EDK peripheral with FIFO Coregen 2.3 included. In ISE peripheral project everything is working fine (FIFO netlist is included and properly sinthesized and built), but in EDK flow every time i get an error during bulid: "unresolved FIFO - missing netlist or pin misspeling can cause this..." I have of course included in MPD: OPTION IMP_NETLIST = TRUE OPTION STYLE = MIX OPTION RUN_NGCBUILD = TRUE and in BDD file: Files async_fifo.edn async_fifo_fifo_generator_v2_3_fifo16_1.edn and in PAO FIFO wrapper: lib peripheral_v1_00_a async_fifo vhdl but the problem persists (and eating my nerves :( ). Files are not properly copied (included) to project implementation directory. I managed to resolve the problem by manually copying netlists to the imp directory, but that is not what I want. My methodology obviously doesn't work. Does anyone knows the proper procedure to fix this (or is maybe willing to give an example)? Cheers, GuruArticle: 106274
Aurelian Lazarut wrote: > I would check (at least) two things, > 1. If the board finishes the configuration process gracefully, I mean > DONE goes high, start-up clock need to be matched with your config type > (jtagclk or cclk or userclk) mode pins are set correctly. But beware of in slave select-map mode, when DONE really means "not quite done yet" or "you're almost done". By default, CCLK has to be strobed several more times after DONE goes high. Have fun, Marc
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