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
Josip <josip@yopmail.com> wrote: > Hi > I would like to build DSP blocks in VHDL, and add a few instances of > each in FPGA chip. After that I would use microcontroler to > control the processing chain for one signal bus. > For example, 16-bit audio signal could be routed like this: input -> > band-pass -> compressor -> echo -> output. I would > like to make as many combinations possible. If that's not possible, > the blocks could be grouped in stages, and signal routing would be > limited to choosing one block from each stage. > To summarise: all DSP blocks would be synthesised and programmed > only once on FPGA device (I would have to make sure they are > spread apart, so there's enough LUTs between for > signal routing). While device is in use, it would be > partially reprogrammed to redirect signal path through device. > How hard would it be to do this, and what are alternative ways > to achieve something similar? Aren't the parts used for that purpose called Multiplexers and Demultiplexers? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 136726
Josip wrote: > I would like to build DSP blocks in VHDL, and add a few instances of each in > FPGA chip. After that I would use microcontroler to control the processing > chain for one signal bus. > For example, 16-bit audio signal could be routed like this: input -> > band-pass -> compressor -> echo -> output. > I would like to make as many combinations possible. If that's not possible, > the blocks could be grouped in stages, and signal routing would be limited > to choosing one block from each stage. > To summarise: all DSP blocks would be synthesised and programmed only once > on FPGA device (I would have to make sure they are spread apart, so there's > enough LUTs between for signal routing). While device is in use, it would be > partially reprogrammed to redirect signal path through device. Partial reconfiguration could do that. If it is only a small number of changes, it could be done with ordinary MUX logic, or even tristate logic (which is converted to MUX logic by the tools). > How hard would it be to do this, and what are alternative ways to achieve > something similar? There is literature on partial reconfiguration, so you can read that. Otherwise, how many different combinations do you have? You could just store the different configurations and load the appropriate one. -- glenArticle: 136727
On Wed, 3 Dec 2008 10:34:35 +0100, "Josip" <josip@yopmail.com> wrote: >Hi >I would like to build DSP blocks in VHDL, and add a few instances of each in >FPGA chip. After that I would use microcontroler to control the processing >chain for one signal bus. >For example, 16-bit audio signal could be routed like this: input -> >band-pass -> compressor -> echo -> output. >I would like to make as many combinations possible. If that's not possible, >the blocks could be grouped in stages, and signal routing would be limited >to choosing one block from each stage. >To summarise: all DSP blocks would be synthesised and programmed only once >on FPGA device (I would have to make sure they are spread apart, so there's >enough LUTs between for signal routing). While device is in use, it would be >partially reprogrammed to redirect signal path through device. >How hard would it be to do this, and what are alternative ways to achieve >something similar? If you're doing audio, or even broadcast video, then it's likely that you could clock everything at N times the sample rate. That allows you to run N pipeline stages with all their I/O multiplexed on to the SAME bunch of signals. Not a brilliantly efficient use of FPGA hardware, but it would considerably simplify the switching/routing. There would be just one inter-stage register holding the results from whichever processing block was activated on the last clock; that register then feeds the input to all blocks. When you have played around with this rather flexible architecture and established what you want to do, you can easily create a less flexible architecture that is less greedy of FPGA resources and clock cycles. Just a thought. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 136728
> If you're doing audio, or even broadcast video, then it's > likely that you could clock everything at N times the > sample rate. That allows you to run N pipeline stages > with all their I/O multiplexed on to the SAME bunch of > signals. Not a brilliantly efficient use of FPGA > hardware, but it would considerably simplify the > switching/routing. There would be just one inter-stage > register holding the results from whichever processing > block was activated on the last clock; that register > then feeds the input to all blocks. > > When you have played around with this rather flexible > architecture and established what you want to do, you > can easily create a less flexible architecture that is > less greedy of FPGA resources and clock cycles. > > Just a thought. > -- > Jonathan Bromley, Consultant It seems like a great idea for prototyping. The possiblities are really endless, as I can pass the signal through the same blocks any number of times without changing the structure. I will need more hands-on experience to estimate how many DSP blocks could my target device hold with such architecture. Thanks alot for your insight. JosipArticle: 136729
Hello, I am running a back-annotated timing simulation with Modelsim, on the post-placement&routing VHDL code generated by ISE(Xilinx tool). This VHDL code does not have the initial design signal names or structures, as it comprises only by device-specific components instantiations. This makes debugging very hard. Does anyone know how I can find the correspondance between initial signals' names and post-routed signals? Does ISE provide this information? Thank you in advance Giorgos P.Article: 136730
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message news:gh5k2r$ij7$1@lnx107.hrz.tu-darmstadt.de... > Josip <josip@yopmail.com> wrote: >> Hi >> I would like to build DSP blocks in VHDL, and add a few instances of >> each in FPGA chip. After that I would use microcontroler to >> control the processing chain for one signal bus. >> For example, 16-bit audio signal could be routed like this: input -> >> band-pass -> compressor -> echo -> output. I would >> like to make as many combinations possible. If that's not possible, >> the blocks could be grouped in stages, and signal routing would be >> limited to choosing one block from each stage. >> To summarise: all DSP blocks would be synthesised and programmed >> only once on FPGA device (I would have to make sure they are >> spread apart, so there's enough LUTs between for >> signal routing). While device is in use, it would be >> partially reprogrammed to redirect signal path through device. >> How hard would it be to do this, and what are alternative ways >> to achieve something similar? > > Aren't the parts used for that purpose called Multiplexers and > Demultiplexers? > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Yes, you are right. If I predefine all possible signal paths, I can use demultiplexors to select one path. If my blocks are grouped in stages, I don't need even mux and demux, I can use a buffer to store signal value between stages. What I would prefer is to have no predefined paths, but to redirect signal around the FPGA CLB blocks as I see fit. JosipArticle: 136731
> Partial reconfiguration could do that. If it is only a small number > of changes, it could be done with ordinary MUX logic, or even > tristate logic (which is converted to MUX logic by the tools). > >> How hard would it be to do this, and what are alternative ways to achieve >> something similar? > > There is literature on partial reconfiguration, so you can read that. > > Otherwise, how many different combinations do you have? You could > just store the different configurations and load the appropriate one. > > -- glen > Can you give me an insight how complicated it is to partially program FPGA device to create a 16-bit link between two blocks? Or to change select bits in mux? I'm familiar wih FPGA architecture, but I don't know much about the process of programming the device. How open is the process? Would I have to reverse engineer to find out what bits correspond to a certian CLB? Thanks JosipArticle: 136732
On Wed, 3 Dec 2008 13:17:00 +0100, "Josip" <josip@yopmail.com> wrote: >> [...] run N pipeline stages >> with all their I/O multiplexed on to the SAME bunch of >> signals. >It seems like a great idea for prototyping. The possiblities are really >endless, as I can pass the signal through the same blocks any number of >times without changing the structure. [...] >Thanks alot for your insight. No insight, just idle coffee-time speculation. In fact, it makes your FPGA look rather like the datapath of a specialized DSP processor.... perhaps you could then put a programmable state machine or small processor on it, and write code for it :-) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 136733
reganireland@gmail.com writes: <snip> > Any ideas? Can you specify any constraints for non top modules? Hi, Yes you can - you just need to find out what the things you want to constrain are called now that they are one-level down. If you open the NCD in FPGA editor, you should be able to find the things you are trying to constrain, and the hierarchical pathname they've been given by the tools. There's probably a /toplevelname/ prepended to them all. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 136734
The problem releated to the memory is solved after I installed ISE 9.2 sp4 and EDK 9.2 sp2. On Dec 1, 10:56=A0pm, SUMAN <suman...@gmail.com> wrote: > No , I have not. I am planning to install them.Article: 136735
On Wed, 03 Dec 2008 10:57:23 +0000, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Wed, 3 Dec 2008 10:34:35 +0100, "Josip" <josip@yopmail.com> wrote: > >>Hi >>I would like to build DSP blocks in VHDL, and add a few instances of each in >>FPGA chip. After that I would use microcontroler to control the processing >>chain for one signal bus. >>For example, 16-bit audio signal could be routed like this: input -> >>band-pass -> compressor -> echo -> output. >>I would like to make as many combinations possible. If that's not possible, >>the blocks could be grouped in stages, and signal routing would be limited >>to choosing one block from each stage. >>To summarise: all DSP blocks would be synthesised and programmed only once >>on FPGA device (I would have to make sure they are spread apart, so there's >>enough LUTs between for signal routing). While device is in use, it would be >>partially reprogrammed to redirect signal path through device. >>How hard would it be to do this, and what are alternative ways to achieve >>something similar? > >If you're doing audio, or even broadcast video, then it's >likely that you could clock everything at N times the >sample rate. That allows you to run N pipeline stages >with all their I/O multiplexed on to the SAME bunch of >signals. Not a brilliantly efficient use of FPGA >hardware, but it would considerably simplify the >switching/routing. There would be just one inter-stage >register holding the results from whichever processing >block was activated on the last clock; that register >then feeds the input to all blocks. Ha! That gave me a 25-year flashback... Yes, if you multiplex all your device outputs onto the same bus, in a fixed sequential order, you can create any interconnection simply by picking off the right bus phase for each device input. When each block was a board full of TTL (or an ADC+analog filter) the bus was a backplane... BBC Designs Department did that in the early 80's and it worked pretty well (you could monitor any signal using a DAC with hex switches on the front panel). The same principle was used in a commercial router for broadcast digital audio signals (Probel) I believe it'll still work in an FPGA... - Brian.Article: 136736
On Wed, 3 Dec 2008 04:27:47 -0800 (PST), giorgos.puiklis@gmail.com wrote: >Hello, > >I am running a back-annotated timing simulation with Modelsim, on the >post-placement&routing VHDL code generated by ISE(Xilinx tool). This >VHDL code does not have the initial design signal names or structures, >as it comprises only by device-specific components instantiations. >This makes debugging very hard. > >Does anyone know how I can find the correspondance between initial >signals' names and post-routed signals? Does ISE provide this >information? You can possibly preserve a few specific signal names by adding "keep" attributes. - BrianArticle: 136737
Here is a presentation I did a while ago summarizing the VHDL packages, arithmetic , coding styles and the new features of VHDL-200x. http://www.slideshare.net/akhailtash/vhdl-arithmetic-presentation/ Enjoy, -- AmalArticle: 136738
>Hi guys >I'm a newbie in the fpga world, i'm studying for myself and the xilinx >documentation is not helping in anything. > >I faced exactly the same problem as Simon > >>I run the on-board 125MHz clock through a DCM to get a 62.5MHz clock. >>This clock goes out of a pad towards the sampler, and the bits come back >>from the sampler. But, depending on rather unrelated changes in my VHDL, >>sometimes I get perfect samples showing the sine output from my signal >>generator, and sometimes there are all kinds of 'jaggies' indicating >>that I'm catching some bits either too late or too early. > >But in my case the on-board clock is 50MHz and i generate with DCM a >100MHz clock(clk) that goes in a BUFG. This clock goes to 2 pads(enca and >encb) towards 2 ADC of 100MHz. Than i get the bits from the ADC in an IOB. > >Here is the important part of my top file: > >entity top is > port ( clk2 : in STD_LOGIC; > ada : in STD_LOGIC_VECTOR(9 downto 0); > adb : in STD_LOGIC_VECTOR(9 downto 0); > enca : inout STD_LOGIC; > encb : inout STD_LOGIC); >end top; > >architecture stm_top of top is > >signal clk : std_logic; > >--ad >signal ada_sync : std_logic_vector(ada'high downto 0); >signal adb_sync : std_logic_vector(adb'high downto 0); > >begin > >--This unit has a DCM where i get the 100MHz clock >clkunit : entity work.clock_unit > Port Map ( > CLK_IN => clk2, > CLK_SEL => cfgreg(1), > RST => reset, > CLK_OUT => clk > ); > >enca <= clk; >encb <= clk; > >data_sync : process(clk) > > begin > if rising_edge(clk) then > ada_sync <= ada; > adb_sync <= adb; > end if; > end process data_sync; > >end stm_top; > >And here is the ucf part > >#------------------------------------------------------------------------- ># Time Constraints >#------------------------------------------------------------------------- >NET "enca" FAST; >NET "encb" FAST; >NET "clk2" TNM_NET = "clk2"; >TIMESPEC "TS_clk2" = PERIOD "clk2" 19.75 ns HIGH 50 %; >NET "clk" TNM_NET = "clk"; > >INST "enca" TNM = "CLKAD"; >INST "encb" TNM = "CLKAD"; >TIMESPEC "TS_CLKAD_TO_CLK" = FROM "clk" TO "CLKAD" 9.1 ns; > >INST "ada<0>" TNM = "ADCA"; >INST "ada<1>" TNM = "ADCA"; >INST "ada<2>" TNM = "ADCA"; >INST "ada<3>" TNM = "ADCA"; >INST "ada<4>" TNM = "ADCA"; >INST "ada<5>" TNM = "ADCA"; >INST "ada<6>" TNM = "ADCA"; >INST "ada<7>" TNM = "ADCA"; >INST "ada<8>" TNM = "ADCA"; >INST "ada<9>" TNM = "ADCA"; >INST "adb<0>" TNM = "ADCB"; >INST "adb<1>" TNM = "ADCB"; >INST "adb<2>" TNM = "ADCB"; >INST "adb<3>" TNM = "ADCB"; >INST "adb<4>" TNM = "ADCB"; >INST "adb<5>" TNM = "ADCB"; >INST "adb<6>" TNM = "ADCB"; >INST "adb<7>" TNM = "ADCB"; >INST "adb<8>" TNM = "ADCB"; >INST "adb<9>" TNM = "ADCB"; >TIMEGRP "ADCA" OFFSET = IN 7 ns VALID 6.5 ns BEFORE "clk2" HIGH; >TIMEGRP "ADCB" OFFSET = IN 7.4 ns VALID 6.5 ns BEFORE "clk2" HIGH; > >First question: >How do i guarantee that the delay between clk and enca is the same as clk >and encb? > >Second question: >Why do I get 0 paths analyzed when i use this constraint? >TIMESPEC "TS_CLKAD_TO_CLK" = FROM "clk" TO "CLKAD" 9.1 ns; > >And the last one: >When I try to use the IOB register for the ada and adb signals, the 2 >constraints "ADCA" and "ADCB" always falls, why do this happen? >INST "adb_sync_0" IOB = TRUE; >INST "adb_sync_1" IOB = TRUE; >INST "adb_sync_2" IOB = TRUE; >INST "adb_sync_3" IOB = TRUE; >INST "adb_sync_4" IOB = TRUE; >INST "adb_sync_5" IOB = TRUE; >INST "adb_sync_6" IOB = TRUE; >INST "adb_sync_7" IOB = TRUE; >INST "adb_sync_8" IOB = TRUE; >INST "adb_sync_9" IOB = TRUE; >INST "ada_sync_0" IOB = TRUE; >INST "ada_sync_1" IOB = TRUE; >INST "ada_sync_2" IOB = TRUE; >INST "ada_sync_3" IOB = TRUE; >INST "ada_sync_4" IOB = TRUE; >INST "ada_sync_5" IOB = TRUE; >INST "ada_sync_6" IOB = TRUE; >INST "ada_sync_7" IOB = TRUE; >INST "ada_sync_8" IOB = TRUE; >INST "ada_sync_9" IOB = TRUE; > >I'm wasting a lot of time in this problem and I haven't any progress. > >Thanks everyone > > > > > Someone help, pleaseArticle: 136739
>What I would prefer is to have no predefined paths, but to redirect signal >around the FPGA CLB blocks as I see fit. Isn't that just a multiplexor between stages? Run the data through each block and also around it too. At the output, have a mux to select the through or around. If you pick the around case, you have a lot of useless logic that did a lot of wasted work. So what. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 136740
On 2 =E4=E5=EA, 10:23, John <isuva...@gmail.com> wrote: > Hello! > > =A0I am try to use TCL with libCseJtag.dll from Xilinx chipscope. I try > set pins like TCK, TDI, TMS by script. > =A0Like it descibe at ug029.pdf: > =A0 =A0For example clock I can run in the loop: > =A0 =A0 csejtag_target set_pin $handle $CSEJTAG_TCK 0 > =A0 =A0 csejtag_target set_pin $handle $CSEJTAG_TCK 1 > > =A0Script work, not get any error. Chaining correctly done and all good, > BUT! =A0TCK, TDI, TMS by this commands not set! > =A0Any body try to do this? > > Best Regards, > Ivan I can remodify my qestion: May task can be made with JTAG Loader from Ken Chapman for Picoblaze, but it not work with Xilinx USB JTAG. What I need to do?Article: 136741
On Dec 3, 8:32=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > reganirel...@gmail.com writes: > > <snip> > > > Any ideas? Can you specify any constraints for non top modules? > > Hi, > > Yes you can - you just need to find out what the things you want to > constrain are called now that they are one-level down. =A0If you open > the NCD in FPGA editor, you should be able to find the things you are > trying to constrain, and the hierarchical pathname they've been given > by the tools. =A0There's probably a /toplevelname/ prepended to them > all. > > Cheers, > Martin > > -- > martin.j.thomp...@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://w= ww.conekt.net/electronics.html Also note that you can use wildcards in the ucf for net names or instance names like NET "*/foobar" LOC =3D "AB12" ; Then you can have constraints that don't break if you change instance names. Just remember that this can create problems if the expanded wildcard name is not unique. Regards, GaborArticle: 136742
On Dec 3, 2:10=A0am, Muzaffer Kal <k...@dspia.com> wrote: > On Tue, 2 Dec 2008 22:10:16 -0800 (PST), carl.horto...@gmail.com > wrote: > > >Hello, There > > >I read from the following from Wikipedia. > > >When connecting flip-flops in a chain, it is important to ensure that > >the tCO of the first flip-flop is longer than the hold time (tH) of > >the second flip-flop, otherwise the second flip-flop will not receive > >the data reliably. > > >http://en.wikipedia.org/wiki/D_flip_flop#D_flip-flop > > >Could someone help to explain why tCO > tH will ensure the second flip- > >flop receive data reliably? > > Before I answer your question I'd like to clarify the quote. The said > condition is only true when the clock pins of the two flops have > absolutely zero skew. The more accurate equation is > tCK1 + tCO > =A0tCK2 + tH ie the clock arrival time to the the source > clock plus the clock to output delay should be greater than clock > arrival time to the target flop plus the hold time. This fact, > especially in an ASIC, is very helpful for fixing hold violations. > > Now the answer to original question relates to the definition of hold. > This constraint requires that the data at the input of a flop should > stay stable a certain amount of time (tH) after the clock edge has > arrived. Assuming zero-skew clocks for the two flops, if tCO is larger > than tH, the input of the second flop will not change earlier than tCO > after the clock edge and this will satisfy the hold constraint. > > Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Serviceshttp://www.dspia.com Actually tCO in the above equation needs to include the minimum routing delay as well as the clock to output time of the flop. In an FPGA, the routing delays are often longer than the logic delays. Xilinx has an appnote on how their timing analyzer calculates setup and hold times. For me it's a little like looking at accounting methods, because although the calculated answer is correct, the way they present the arithmetic is not the way you would normally think of the problem. By the way the Wikipedia equation was good enough in the old days where the logic delays of TTL chips was orders of magnitude greater than the wiring delays. Inside FPGA's routing delay can dominate the total timing. However internal hold time violations are uncommon in FPGA's because the clock routing is designed for very low skew. Internal hold time violations usually only show up when not using the dedicated clock routing resources. Regards, GaborArticle: 136743
Hello, I have a design which I am porting to a Cyclone II FPGA. This design includes two clocks, one at 25 MHz and one at 100 MHz, currently generated from the Cyclone II PLL from a common clock (and thus synchronous.) I have avoided it so far, but I'm running into a situation where the high-speed logic would like to understand where it is in relation to the low-speed clock cycle, in order to generate clock enables. In particular, part of the high-speed logic drives an external SRAM which I'd like to time division multiplex between two of the low-speed units. The SRAM is fast enough to do that. However, I can't seem to figure out a reasonable way to generate the necessary clock enables, other than switching the 25 MHz clock to be generated from a counter or shift register implemented in LUTs rather than using the dedicated PLL logic. The obvious solution of sampling the 25 MHz clock output in the 100 MHz clock domain seems like it would fail since the clocks transition at the same time, effectively a setup/hold violation. -hpaArticle: 136744
On Wed, 03 Dec 2008 13:27:45 -0800, "H. Peter Anvin" <hpa@zytor.com> wrote: >Hello, > >I have a design which I am porting to a Cyclone II FPGA. This design >includes two clocks, one at 25 MHz and one at 100 MHz, currently >generated from the Cyclone II PLL from a common clock (and thus >synchronous.) I have avoided it so far, but I'm running into a >situation where the high-speed logic would like to understand where it >is in relation to the low-speed clock cycle, in order to generate clock >enables. > >In particular, part of the high-speed logic drives an external SRAM >which I'd like to time division multiplex between two of the low-speed >units. The SRAM is fast enough to do that. However, I can't seem to >figure out a reasonable way to generate the necessary clock enables, >other than switching the 25 MHz clock to be generated from a counter or >shift register implemented in LUTs rather than using the dedicated PLL >logic. The obvious solution of sampling the 25 MHz clock output in the >100 MHz clock domain seems like it would fail since the clocks >transition at the same time, effectively a setup/hold violation. If you tell the PLL to create the two clocks with zero skew, you can move signals seamlessly from one clock domain to the other and the timing analyzer will take care of all the setup/hold issues - at least, it works with TimeQuest; I've not tried to use the "classic" STA in such situations. To get a counter in the fast clock domain correctly sync'd with the slow clock, I guess you could consider sampling the slow clock on the inactive edges of the fast one. That should give plenty of setup time. I agree, though, that it seems like duplication of work that the PLL has already done. Alternatively, get the PLL to emit a second 25MHz clock with a suitable phase offset relative to the main 25MHz, and use that as your synch signal. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 136745
On Dec 3, 4:27=A0pm, "H. Peter Anvin" <h...@zytor.com> wrote: > Hello, > > I have a design which I am porting to a Cyclone II FPGA. =A0This design > includes two clocks, one at 25 MHz and one at 100 MHz, currently > generated from the Cyclone II PLL from a common clock (and thus > synchronous.) =A0I have avoided it so far, but I'm running into a > situation where the high-speed logic would like to understand where it > is in relation to the low-speed clock cycle, in order to generate clock > enables. > Use the 25 MHz clock to simply toggle a flip flop. Then in the 100 MHz domain look for a change from one 100 MHz clock to the next in the state of that flop to tell you that an edge occurred on the previous clock cycle (or a 0 to 1 change to tell you that it was a rising edge). That flop change can be used to initialize a 2 bit counter in the 100 MHz domain so it can know exactly what phase the 25 MHz clock is in right now. Kevin JenningsArticle: 136746
> The obvious solution of sampling the 25 MHz clock output in the >100 MHz clock domain seems like it would fail since the clocks >transition at the same time, effectively a setup/hold violation. You can kludge in a lot of delay. :( One clean way is to look at a FF clocked by the 25 MHz clock rather than the raw 25 MHz clock. You can either find an edge and just keep counting from there or make a FF that toggles on each 25 MHz clock and restart your state machine each toggle. You have to make sure the skew between your two clocks is low enough not to cause problems. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 136747
Jonathan Bromley wrote: > To get a counter in the fast clock domain correctly > sync'd with the slow clock, I guess you could consider > sampling the slow clock on the inactive edges of the fast > one. That should give plenty of setup time. I agree, > though, that it seems like duplication of work that > the PLL has already done. Duplication of work, sure, but's only a few FFs worth. This seems to be a sensible solution. The technique suggested by KJ and Hal, to sample not the 25 MHz clock but a FF toggled by it seems like it should work fine, too. Hal Murray wrote: > You have to make sure the skew between your two clocks is > low enough not to cause problems. That shouldn't be a problem per se; the timing analyzer should catch issues there, and in fact has done so already during development. Thanks guys, I really appreciate it! -hpaArticle: 136748
Thanks guys I was hoping that was the case, seemed logical. Will check it out now, Gints-Article: 136749
On Dec 3, 4:27 pm, "H. Peter Anvin" <h...@zytor.com> wrote: > Hello, > > I have a design which I am porting to a Cyclone II FPGA. This design > includes two clocks, one at 25 MHz and one at 100 MHz, currently > generated from the Cyclone II PLL from a common clock (and thus > synchronous.) I have avoided it so far, but I'm running into a > situation where the high-speed logic would like to understand where it > is in relation to the low-speed clock cycle, in order to generate clock > enables. > Use the 25 MHz clock to simply toggle a flip flop. Then in the 100 MHz domain look for a change from one 100 MHz clock to the next in the state of that flop to tell you that an edge occurred on the previous clock cycle (or a 0 to 1 change to tell you that it was a rising edge). That flop change can be used to initialize a 2 bit counter in the 100 MHz domain so it can know exactly what phase the 25 MHz clock is in right now. Kevin Jennings
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