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
Sven, What is it you wish to accomplish by porting the design ? Are you targeting a specific device or family ? -rajeev- > "Sven T" <hw_engineer@NOSPAMgmx.net> wrote in message news:<ap0bk3$cjq$1@vistranem1.vi.vector.int>... > > Hi there, > > I have the following problem. > > A partner firm has a design implemented on a XILINX Virtex XCV800. > > The design is in VHDL and I want to check if this design can be ported to an > > ALTERA.Article: 48651
If I click on the link: bc6502-base.v (Reference version) I get an error saying the URL does not exist. "Rob Finch" <robfinch@sympatico.ca> wrote in message news:dg2t9.2898$Kf.581559@news20.bellglobal.com... > b.t.w I have verified the latest version of the t80 (z80) core at > > www.opencores.org to be absolutely cycle accurate - at least for all the > > code I have run on it so far - may have missed some though ;-) > > > > Let's start a z80 vs 6502 war :) > > > > I would guess available as in "for license" as in for commercial > payment. > > The core is available for free for individual use or evaluation purposes. > Only commercial use requires a license. > http://www.birdcomputer.ca/Projects/Prj6502/bc6502_page.html > I assumed that people would be able to find this link, but maybe I need to > organize my website a little better... > > > > Does this newsgroup allow commercial advertisements? So... No it is not > > Where do you find the rules of the newsgroup or any newsgroup ? > > Obviously, I should have put more detail in my original post. > > Rob > > >Article: 48652
I ran into a problem which drove me nuts but when I thought about it, it made sense. - I have a signal I am trying to monitor with a state machine - The state machine runs at 25Mhz - The signal to sample incoming comes through an opto coupler and has a slow slew rate. - If I sample the high slew clock at this fast rate the state machine glitches. - I understand (NOW!!) the state machine glitches because I sample while the signal is in the undefined point anround half Vcc or whatever where the input can't decided if it is low or high so sometimes 2 samples in here are seen as high an low and thus my state machine glitches. SOLUTIONS I CANT DO THAT WOULD WORK 1.) Put a schmidt trigger on the signal (requires board change) 2.) Slow the state machine down to go over the state machine Can anyone think of a solution that I could implement in VHDL code so I don't have to relay the board? TIA LeonArticle: 48653
Hi
Have you checked the log file permissions?
This file is updated while Modelsim is running.
Maybe a restricted account does not have write permissions on that file
and that confuses the daemon.
Regards
Francisco Rodriguez
====================================================
Francisco Rodriguez Ballester (prodrig@disca.upv.es)
Dept. DISCA, EUI - Univ. Politecnica de Valencia
c/Camino de Vera s/n, E-46022, VALENCIA (SPAIN)
tlf: +(34) 96 387 75 77 - fax: +(34) 96 387 75 79
====================================================
"Kolja Sulimma" <kolja@bnl.gov> escribió en el mensaje
news:25c81abf.0210210939.1a50edd9@posting.google.com...
> I hope that somebody out there can help me with this installation
> issue:
>
> For a lab course I need ISE 5.1i to run on a student accessible PC.
> Everything works fine if one is loged into an administrator account.
> But when I try to start Modelsim from a restricted account I get a
> message:
> "Your evaluation license is no longer valid. If this has happened in
> error, please contact Model Technology Customer Support for
> assistance.
> Evaluation Error Code : 104"
>
> The licensing wizard tells me:
> "Your evaluation license has been invalidated because
> a text file necessary for licensing cannot be written.
> In order to continue with the evaluation of Modelsim you will need to
> correct the error, re-install the evaluation copy and re-request
> an evaluation license from Model Technology."
>
> Which is strange, because I do not use an evaluation license.
>
> I checked that the LM_LICENSE_FILE variable for the user points to
> the same license file that the administrator uses.
>
> Of course I contacted modeltech support. They pointed me to the Xilinx
> US support who forward my request to the german support team who just
> don't have
> a clue. (I had to point out some related answers from their database
> before they agreed that apparently ISE is supposed to work for
> restricted users)
>
> So, anybody know which file permissions need to be changed to get this
> working?
>
> Thanks in advance,
>
> Kolja Sulimma
Article: 48654Not absolutely sure what you mean by state machine glitches. What is the slew rate of your incoming signal and what is the frequency of this signal. Additionaly I think you are facing a metastability problem. If the frequency of your incoming signal is lower that the fsm's frequency you can use a sync stage. Just use 2 ffs in series to sample the incoming data. The output of your second ff can be used to feed the fsm. You can also use these two ffs for edge detection. HTH Ansgar -- Attention please, reply address is invalid, please remove "_xxx_" ro reply "Leon de Boer" <ldeboer@attglobal.net> schrieb im Newsbeitrag news:3db567c7_3@news1.prserv.net... > I ran into a problem which drove me nuts but when I thought about it, it > made sense. > > - I have a signal I am trying to monitor with a state machine > - The state machine runs at 25Mhz > - The signal to sample incoming comes through an opto coupler and has a slow > slew rate. > - If I sample the high slew clock at this fast rate the state machine > glitches. > - I understand (NOW!!) the state machine glitches because I sample while the > signal is in the undefined point anround half Vcc or whatever where the > input can't decided if it is low or high so sometimes 2 samples in here are > seen as high an low and thus my state machine glitches. > > SOLUTIONS I CANT DO THAT WOULD WORK > 1.) Put a schmidt trigger on the signal (requires board change) > 2.) Slow the state machine down to go over the state machine > > Can anyone think of a solution that I could implement in VHDL code so I > don't have to relay the board? > > TIA Leon > > > >Article: 48655
Thanks for your responses. As you said, it seems OK to run quartus under Linux. In fact, as we also have Sun workstations, we are able to run it over the network. Our main problem is the use of NIOS tools such as nios-run with linux. How does it work to use the serial port to communicate with the dev board over the serial link with a linux workstation ? Thank you very much Stephane > I run Quartus using Mandrake 8.0. > I have not run into many problems with Quartus for Linux, other than the > windows that sometime dissapear (esp when opening a Megawizard function, for > example). >Article: 48656
Leon,
A few ideas...
1. Can you oversample the data in some fashion and then look for more
that just 1 changed bit?
2. Can you use a different type of opto-coupler such as one with either a
higher gain or a built-in Schmidt trigger?
3. Depending on the configuration could you use a non-opto isolator such
as the iso-loop parts from nve corp? http://www.nve.com (I have used these
at 100 megabaud and they are available from Digikey. Cost seems to be
reasonable given Digikey as a distributor.)
Theron
"Leon de Boer" <ldeboer@attglobal.net> wrote in message
news:3db567c7_3@news1.prserv.net...
> I ran into a problem which drove me nuts but when I thought about it, it
> made sense.
>
> - I have a signal I am trying to monitor with a state machine
> - The state machine runs at 25Mhz
> - The signal to sample incoming comes through an opto coupler and has a
slow
> slew rate.
> - If I sample the high slew clock at this fast rate the state machine
> glitches.
> - I understand (NOW!!) the state machine glitches because I sample while
the
> signal is in the undefined point anround half Vcc or whatever where the
> input can't decided if it is low or high so sometimes 2 samples in here
are
> seen as high an low and thus my state machine glitches.
>
> SOLUTIONS I CANT DO THAT WOULD WORK
> 1.) Put a schmidt trigger on the signal (requires board change)
> 2.) Slow the state machine down to go over the state machine
>
> Can anyone think of a solution that I could implement in VHDL code so I
> don't have to relay the board?
>
> TIA Leon
>
>
>
>
Article: 48657Leon, You are completely correct in your assesment of what is happening. One way to deal with slow rising signals that may have noise on them is to add states to the state machine. If it senses a 'high', it then goes to a "check that it is really going high+1" state where on the next state machine clock, it checks again to see if it is still high. One might have to add as many as 128 checks (or more) for high, or low, depending on the state machine clock rate, and the rise and fall times of the slow signal. If any sample disagrees, then the state returns to the beginning where it starts all over checking for a change. Austin Leon de Boer wrote: > I ran into a problem which drove me nuts but when I thought about it, it > made sense. > > - I have a signal I am trying to monitor with a state machine > - The state machine runs at 25Mhz > - The signal to sample incoming comes through an opto coupler and has a slow > slew rate. > - If I sample the high slew clock at this fast rate the state machine > glitches. > - I understand (NOW!!) the state machine glitches because I sample while the > signal is in the undefined point anround half Vcc or whatever where the > input can't decided if it is low or high so sometimes 2 samples in here are > seen as high an low and thus my state machine glitches. > > SOLUTIONS I CANT DO THAT WOULD WORK > 1.) Put a schmidt trigger on the signal (requires board change) > 2.) Slow the state machine down to go over the state machine > > Can anyone think of a solution that I could implement in VHDL code so I > don't have to relay the board? > > TIA LeonArticle: 48658
Hi, I can only agree with Ray. My coding is mostly instanciation of Xilinx primitive surrounded with generate statement and generics. I have also found out that it takes me roughly 5-10 minutes to write the above combined adder/mux using LUT,MUXCY,XORCY and generate statements. It can take me almost a day trying to foul one synthesis tool to do the same and I might have to redo that day when I change synthesis tool or get a new version. I just want most result of the effort I put in my work and that's why roughly 90% of MicroBlaze is directly instanciated Xilinx primitives. What I also get by instanciating the primitives is a possibility of controlling the placement, which is much tougher if you stick to RTL. It's extremely easy to floorplan the above module and getting maximum performance. Why only 90% not 100% in MicroBlaze? Sometimes I know that even the stupidest synthesis tool can't go wrong and it's not in a critical section. Doing large boolean expression is faster in RTL and most synthesis tool can handle that. Göran Ray Andraka wrote: > Jan, Ralph, > > Long time ago we got tired of pushing on the rope for every design we did, so we > went ahead and created a library of parameterized structurally instantiated > things like d registers, various flavors of adders/subtractors, delay queues, > etc. Easy to do in VHDL with the generate statement, a real PITA in verilog > without the v2000 extensions. Because of some of the things like the generate, > I have become something of a VHDL bigot so you'll have to excuse that. Usually > I could get the tools to behave with inferred stuff if I structured the > inference to look like the hardware, something like this: > > neg_b<= b when sub='1' else not b; > cin<= 1 when sub='1' else 0; > sum_d<= a + neg_b+cin; > > The results vary by synth and version, but this structure seems to get there > most of the time. > > Jan Gray wrote: > > > Ralph Mason wrote > > > > > 1. As a learning process I have copped his adder, he says that it turns > > > into 17 LUT's although mine ends up at 52 - Is there some optimizations I > > am > > > missing here? are there any pragmas you can use in these situations to say > > > what you want? Can you get right down to the actual LUT level and connect > > > them up yourself? Using the free Xilinx tools can you actually see the way > > > it has connected the actual LUTs? > > > > First, congratulations on going to the trouble of actually looking under the > > hood and *inspecting* what came out of your tools. That is a very good > > practice. > > > > Welcome to "pushing on a rope". (fpgacpu.org/usenet/rope_pushing.html: "You > > know exactly what you want -- a particular optimal, hand-mapped, hand-placed > > layout for your datapath -- but the tools get in the way, and you spend > > hours trying to discover an incantation that persuades the tools to emit the > > desired result.") > > > > Here the goal was to generate a+b or a-b with cin and cout at a cost of one > > LUT per bit. The hardware is willing, but you will need to perform a bit of > > experimentation to discover an expression that the synthesis tool will > > repeatably synthesize into the desired hardware idiom. > > > > The construction you 'copped' did work for one version of some synthesis > > tool once. Of course that does not mean it works reliably across all tools > > and all versions of all tools! > > > > I like John_H's suggestion -- it may succeed more often than the mux(+,-) > > that I used. > > > > BTW IIRC in this specific instance it was also necessary to move the single > > assignment into its own module -- the synthesis tool created the inefficient > > mux(+, -) form if the assignment was inline in the parent module. > > > > > 2. Floorplaning - Is there any info on this, it seems that you don't need > > > to do it because the tools do it automatically, I am guessing sometimes > > you > > > can do it better yourself to give a faster device? It looks like a > > > laborious process - is it? > > > > It need not be laborious, but you have to learn the ropes. It think we old > > timers are fortunate because we grew up doing hierarchical schematics, and > > so writing the same hierarchical structural HDL is familiar and natural. > > > > It is long past time I investigated how to do this with XST Verilog and > > wrote it up for my site... > > > > > 3. General - The CPU I want to design is a RISC / CISC design where a pre > > > processor reads CISC instructions from ram and places RISC instructions > > (or > > > jumps to RISC subs) to do the same them in an internal pipeline for a > > RISC > > > internal cpu ( or perhaps many instances of the same RISC cpu and a single > > > pre processor to provide a kind of hardware multithreading) - Is there any > > > notes on existing designs like this that one could read. > > > > Interesting. If the "preprocessor" is hardware, this was done in e.g. Intel > > P6, in the AMD K6, in some VAX implementations, and so forth. If the > > "preprocessor" is software, this was done in e.g. SoftWindows, Digital's > > FX!32 and Transmeta. There's lots in the library (see e.g. IEEE Micro) and > > in Google! (Also time to update my resources/book section of my site.) > > > > Jan Gray, Gray Research LLC > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 48659
Leon de Boer wrote:
> - I have a signal I am trying to monitor with a state machine
> - The state machine runs at 25Mhz
> - The signal to sample incoming comes through an opto coupler and has a slow
> slew rate.
> - If I sample the high slew clock at this fast rate the state machine
> glitches.
Consider synchronizing all inputs to the state machine to the 25Mhz clock.
-- Mike Treseler
Article: 48660I support Austin's idea of filtering the input signal with a digital low-pass filter. But there may also be another solution. You don't like to add a Schmitt trigger because that would change the pc-board. Well, it doesn't have to. Depending on the output impedance of your optocoupler, you can achieve Schmitt-trigger performance if you drive the input signal non-inverted back onto the same pin. Make the output drive as week as you can ( 2 mA) which means about 100 to 200 Ohm. If the optocoupler output impedance is in the 50 to 100 Ohm range, you might have a nice hysteresis on the input... Peter Alfke ================= Leon de Boer wrote: > I ran into a problem which drove me nuts but when I thought about it, it > made sense. > > - I have a signal I am trying to monitor with a state machine > - The state machine runs at 25Mhz > - The signal to sample incoming comes through an opto coupler and has a slow > slew rate. > - If I sample the high slew clock at this fast rate the state machine > glitches. > - I understand (NOW!!) the state machine glitches because I sample while the > signal is in the undefined point anround half Vcc or whatever where the > input can't decided if it is low or high so sometimes 2 samples in here are > seen as high an low and thus my state machine glitches. > > SOLUTIONS I CANT DO THAT WOULD WORK > 1.) Put a schmidt trigger on the signal (requires board change) > 2.) Slow the state machine down to go over the state machine > > Can anyone think of a solution that I could implement in VHDL code so I > don't have to relay the board? > > TIA LeonArticle: 48661
Ours has a high degree of instantiation in stuff that gets used alot...adders, d
registers, delay queues etc are all 100%. For less often used, I'll often use the D
register then use RTL to describe the LUTs in front of it and let the mapper worry about
placing them, and for some of the control logic I just go to an all RTL taking care to
keep the inputs to the logic in front each register to 4 or 5. The motivation of course
is design turn time, which includes making the design hit the timing goals. Once you
have a library of some of the basic stuff, putting together pretty complicated data
paths goes quite quickly, and in the end you have a placed component that you know has a
good shot of making timing and should be left alone by the tools.
Goran Bilski wrote:
> Hi,
>
> I can only agree with Ray.
> My coding is mostly instanciation of Xilinx primitive surrounded with generate
> statement and generics.
>
> I have also found out that it takes me roughly 5-10 minutes to write the above
> combined adder/mux using LUT,MUXCY,XORCY and generate statements.
> It can take me almost a day trying to foul one synthesis tool to do the same and I
> might have to redo that day when I change synthesis tool or get a new version.
>
> I just want most result of the effort I put in my work and that's why roughly 90% of
> MicroBlaze is directly instanciated Xilinx primitives.
> What I also get by instanciating the primitives is a possibility of controlling the
> placement, which is much tougher if you stick to RTL.
> It's extremely easy to floorplan the above module and getting maximum performance.
>
> Why only 90% not 100% in MicroBlaze?
> Sometimes I know that even the stupidest synthesis tool can't go wrong and it's not
> in a critical section.
> Doing large boolean expression is faster in RTL and most synthesis tool can handle
> that.
>
> Göran
>
> Ray Andraka wrote:
>
> > Jan, Ralph,
> >
> > Long time ago we got tired of pushing on the rope for every design we did, so we
> > went ahead and created a library of parameterized structurally instantiated
> > things like d registers, various flavors of adders/subtractors, delay queues,
> > etc. Easy to do in VHDL with the generate statement, a real PITA in verilog
> > without the v2000 extensions. Because of some of the things like the generate,
> > I have become something of a VHDL bigot so you'll have to excuse that. Usually
> > I could get the tools to behave with inferred stuff if I structured the
> > inference to look like the hardware, something like this:
> >
> > neg_b<= b when sub='1' else not b;
> > cin<= 1 when sub='1' else 0;
> > sum_d<= a + neg_b+cin;
> >
> > The results vary by synth and version, but this structure seems to get there
> > most of the time.
> >
> > Jan Gray wrote:
> >
> > > Ralph Mason wrote
> > >
> > > > 1. As a learning process I have copped his adder, he says that it turns
> > > > into 17 LUT's although mine ends up at 52 - Is there some optimizations I
> > > am
> > > > missing here? are there any pragmas you can use in these situations to say
> > > > what you want? Can you get right down to the actual LUT level and connect
> > > > them up yourself? Using the free Xilinx tools can you actually see the way
> > > > it has connected the actual LUTs?
> > >
> > > First, congratulations on going to the trouble of actually looking under the
> > > hood and *inspecting* what came out of your tools. That is a very good
> > > practice.
> > >
> > > Welcome to "pushing on a rope". (fpgacpu.org/usenet/rope_pushing.html: "You
> > > know exactly what you want -- a particular optimal, hand-mapped, hand-placed
> > > layout for your datapath -- but the tools get in the way, and you spend
> > > hours trying to discover an incantation that persuades the tools to emit the
> > > desired result.")
> > >
> > > Here the goal was to generate a+b or a-b with cin and cout at a cost of one
> > > LUT per bit. The hardware is willing, but you will need to perform a bit of
> > > experimentation to discover an expression that the synthesis tool will
> > > repeatably synthesize into the desired hardware idiom.
> > >
> > > The construction you 'copped' did work for one version of some synthesis
> > > tool once. Of course that does not mean it works reliably across all tools
> > > and all versions of all tools!
> > >
> > > I like John_H's suggestion -- it may succeed more often than the mux(+,-)
> > > that I used.
> > >
> > > BTW IIRC in this specific instance it was also necessary to move the single
> > > assignment into its own module -- the synthesis tool created the inefficient
> > > mux(+, -) form if the assignment was inline in the parent module.
> > >
> > > > 2. Floorplaning - Is there any info on this, it seems that you don't need
> > > > to do it because the tools do it automatically, I am guessing sometimes
> > > you
> > > > can do it better yourself to give a faster device? It looks like a
> > > > laborious process - is it?
> > >
> > > It need not be laborious, but you have to learn the ropes. It think we old
> > > timers are fortunate because we grew up doing hierarchical schematics, and
> > > so writing the same hierarchical structural HDL is familiar and natural.
> > >
> > > It is long past time I investigated how to do this with XST Verilog and
> > > wrote it up for my site...
> > >
> > > > 3. General - The CPU I want to design is a RISC / CISC design where a pre
> > > > processor reads CISC instructions from ram and places RISC instructions
> > > (or
> > > > jumps to RISC subs) to do the same them in an internal pipeline for a
> > > RISC
> > > > internal cpu ( or perhaps many instances of the same RISC cpu and a single
> > > > pre processor to provide a kind of hardware multithreading) - Is there any
> > > > notes on existing designs like this that one could read.
> > >
> > > Interesting. If the "preprocessor" is hardware, this was done in e.g. Intel
> > > P6, in the AMD K6, in some VAX implementations, and so forth. If the
> > > "preprocessor" is software, this was done in e.g. SoftWindows, Digital's
> > > FX!32 and Transmeta. There's lots in the library (see e.g. IEEE Micro) and
> > > in Google! (Also time to update my resources/book section of my site.)
> > >
> > > Jan Gray, Gray Research LLC
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48662
I'm sorry if this has been posted before. I'm using Virtex2.
I have 600 input/output buffers that I want to run registered (ODFX and
OFDDRTCPE/IFDDRCPE). However, when I plug the CLK in that many places the
timing just goes all to heck. I tried running the clock through a BUFG
first, but the timing is worse off doing that than it was before. I tried
running the clock through a register itself like this:
yada: process(CLK) begin
if(CLK'event) then
if(CLK = '1') then newCLK = '1';
elsif(CLK = '0') then newCLK = '0';
end if;
end if;
end process;
The timing came out great when I did that, but the program wouldn't work
then. I suppose that makes sense because my data coming in with the CLK
would probably be pushed out on the wrong cycle. I'm assuimg the registers
don't lose the 'pulse' effect of the CLK signal.
So my question: how do you clock 600 buffers and still meet the timing
constraints?
Article: 48663Some more on this issue: It ended up that the unstability was caused by running the CLK pin too many places. I cut those lines and things are running much better.Article: 48664
Consider for a moment that the via grid under the part isn't a 31 square solid grid, but four grids of about 15x16 vias. In order to keep the escapes for the outside pins going outside, the vias are going to spread from the center. This effectively leaves an unpopulated row of vias in a 32 square grid that splits the part in half both ways. This is where we'll put 0402 (or 0603) caps to decouple much of the power. There are also those who believe that the center ground vias don't have to all radiate outward; they make a square of vias in the center where the ground vias radiate inward (fewer overall connections to the place) leaving a ring around the center for these tiny caps. If your slew rates and drive strengths aren't extreme, you might get away with having the caps for VCCO around the periphery instead of "within" the part. The overall effect would be - I expect - a degredation of the Simultaneous Switching Output guidelines for the device. Since slower slew, lower drive signals have high SSO pin counts per power/ground, a degradation here wouldn't be bad. Just don't expect flawless operation if you're pushing those SSO numbers. There isn't complete agreement in the engineering community about what really is necessary for decoupling, but good (closely spaced) power and ground planes are an essential start both for the very high frequency distributed capacitance as well as the low impedance paths to the decoupling caps. Albert Ross wrote: > The Xilinx guidelines recommend one HF cap per supply pin (VCCINT, > VCCO, VCCAUX), yet the power pins are mostly in the centre of the > chip. Assuming one via per pin, how have people managed to place > decouplers close to these pins on the underside of the board to > minimise trace length? Is it adequate to place the decouplers around > the periphery of the chip, or is the only solution to use buried / > blind vias with caps underneath the chip? > Having viewed the recommended standard routing diagrams in the Virtex > II databook it shows there is no unused area in the centre of the chip > as there are in some of the BG packages for Virtex E. > Has anyone got any words of wisdom? > 'Bert RossArticle: 48665
FYI, Received new brochure from KluwerAcademic Publishers. Link: http://members.cox.net/vhdlcohen/vhdlcode/SOCbrochure.pdf Hope you'll find it useful. BenArticle: 48666
"Brannon King" <bking@starbridgesystems.com> schrieb im Newsbeitrag
news:3db5867f@news.splitrock.net...
> I'm sorry if this has been posted before. I'm using Virtex2.
>
> I have 600 input/output buffers that I want to run registered (ODFX and
> OFDDRTCPE/IFDDRCPE). However, when I plug the CLK in that many places the
> timing just goes all to heck. I tried running the clock through a BUFG
> first, but the timing is worse off doing that than it was before. I tried
> running the clock through a register itself like this:
>
> yada: process(CLK) begin
> if(CLK'event) then
> if(CLK = '1') then newCLK = '1';
> elsif(CLK = '0') then newCLK = '0';
> end if;
> end if;
> end process;
>
> The timing came out great when I did that, but the program wouldn't work
> then. I suppose that makes sense because my data coming in with the CLK
> would probably be pushed out on the wrong cycle. I'm assuimg the registers
> don't lose the 'pulse' effect of the CLK signal.
>
> So my question: how do you clock 600 buffers and still meet the timing
> constraints?
By doing it just right.
signal data_internal : std_logic_vector (599 downto 0);
process(clk)
begin
if clk='1' and clk'event then
data_internal <= data_from_outside;
end if;
end process;
Article: 48667
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag
news:3DB574EB.3286B6B4@xilinx.com...
> I support Austin's idea of filtering the input signal with a digital
low-pass
> filter.
I would go for the digital low pass filter. Make a shift register, lets say
4 bits. Shift you input sinal into this register. Then another (5th)
FlipFLop is loaded with '1', when the register is "1111", and with "0" wheh
the register is "0000", all other codes of the register leave the state of
the FlipFlop unaltered.
In VHDL this looks like this.
signal shift : std_logic_vector (3 downto 0);
signal clean_input : std_logic;
process(clk25MHz)
begin
if clk25MHz=1 and clk25MHz'event then
shift <= shift(2 downto 0) & data_from_opto;
if shift="0000" then
clean_signal <='0';
elsif shift="1111" then
clean_signal <= '1';
end if;
end if;
end process;
The shift register should be long enough to cover the whole rise/fall time
of the signal, e.g. if the rise/fall time is 1us (sloooooow), then it must
be 25 stages (if you run @25 MHz)
--
MfG
Falk
Article: 48668The Xilinx Answer Record states that the RocketI/Os on the V2Pro have been tested and verified to work with 1000BASE-SX (fiber Gb ethernet, multimode fiber). The media for 1000BASE-T however is a 4 pair differential signaling, rather than the serial send/receive of the fiber standards. Are there low cost solutions for driving 1000BASE-T ethernet using the RocketI/Os? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48669
> By doing it just right. > > signal data_internal : std_logic_vector (599 downto 0); > > process(clk) > begin > if clk='1' and clk'event then > data_internal <= data_from_outside; > end if; > end process; I understand that the above code would do a fine job of instantiating normal buffers. So if I have 10 sets of 32pins that all need to be R/W DDR (=640 buffers) with T plugged into a separate input (I also have C0 => CLK, C1 => not CLK), how would I declare them as such in one big chunk without manually declaring the components and plugging the CLK into all of them? Is that what you are inferring I should do?Article: 48670
Someone know where to buy fpga (Xilinx,Altera) in quantities of 1 to 5 in Mexico or Usa ?? thanks in advanceArticle: 48671
Hi, We are making Download ByteBlasterMV for Altera FPGA and EPLD configuration/programming. It's reliable, affordale and suitable for PLD development and somebody who want's to learn PLD. Details please check at: http://www.minford.ca. Minford TechnologyArticle: 48672
Hi, I am building a circuit that requires a 120MHz clock and a 24MHz clock and they also need to be synchronous. Is there a "divide by 5" clock divider chip I could use to get the synchronous 24MHz clock from the 120Mhz clock? cheers, Jamie MorkenArticle: 48673
Leon de Boer wrote: > > I ran into a problem which drove me nuts but when I thought about it, it > made sense. > > - I have a signal I am trying to monitor with a state machine > - The state machine runs at 25Mhz > - The signal to sample incoming comes through an opto coupler and has a slow > slew rate. > - If I sample the high slew clock at this fast rate the state machine > glitches. > - I understand (NOW!!) the state machine glitches because I sample while the > signal is in the undefined point anround half Vcc or whatever where the > input can't decided if it is low or high so sometimes 2 samples in here are > seen as high an low and thus my state machine glitches. Correct - when running state machines from async IPs ( including those with perfect rise times ) it is important to avoid aperture effects, where more than one State Bit depends on the IP at a given time. Whilst it is possible to code such state machines, it can be much simpler to add at least one syncronising flip-flop to the IP. An additional voting noise filter can help, esp if the state engine actually has a MIN HI or LOW requirement - many do, and you should check what your effective Fmax IP is, and design a noise filter/vote scheme to keep under that. The Shift register + Sticky Bit filter idea already proposed is a good one. > > SOLUTIONS I CANT DO THAT WOULD WORK > 1.) Put a schmidt trigger on the signal (requires board change) > 2.) Slow the state machine down to go over the state machine > > Can anyone think of a solution that I could implement in VHDL code so I > don't have to relay the board? For testing, add a Schmitt to the path ( eg Schmitt opto H11L1/better, or TinylLogic 1G17 ) and check it actually works 100.00% Apply the coding changes, until it worka 100.00%, then remove the schmitt, and check it is still OK. -jgArticle: 48674
Any programmable device can divide 120 MHz by five inside the chip. Xilinx Virtex devices have a built-in delay-locked loop (DLL) circuit that can divide the clock by 5 ( and also many other values) and guaranteed that the 24 MHz output edges are synchronous and coincident ( within <100 ps) with the incoming 120 MHz rising clock edge. Without using the DLL or DCM your derived clock will trail the input clock by 1 to 2 ns. (clock-to-Q plus some routing) Peter Alfke, Xilinx Applications. ====================== Jamie Morken wrote: > Hi, > > I am building a circuit that requires a 120MHz clock and a 24MHz clock and > they also need to be synchronous. Is there a "divide by 5" clock divider > chip I could use to get the synchronous 24MHz clock from the 120Mhz clock? > > cheers, > Jamie Morken
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