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
I have routinely started saving a copy of the .ise project away so that when ISE 8.2.03 trashes the file, I can copy it back. This has saved me several times recently. Navigator is one buggy tool. There is a tcl script to let you export the file names from the binary database, but my experiments show you can't use it to import files into an ise project if they don't already exist in the project. Also, the tcl script requires that the .ise project exist already. I hope the 9.x release of the tools is better than 8.x John Providnza Gabor wrote: > marc_ely wrote: > > Hi > > > > A couple of months ago I had to move up to ISE 8.2 once 7.1 stopped > > meeting my timings. Since I moved I have had nothing but problems with > > project files and their corruption. > > I have finally settled on 8.2.3 as it appeared more stable than older > > patched versions. 8.2.0 was dire. > > > > The project file corruptions seem to occur randomly and will do various > > things, such as remove all files from the project (and not let you add > > them back), or not let you edit coregen parts, or a host of other > > things. > > > > Re-creating a project each time seems very laborious. Does anyone have > > any shortcuts to do this? Is there a TCL script that can be run? > > Archiving and Project Cleanup don't help. > > > > The project is a mix of VHDL, verilog and coregen parts (xaw and xco). > > > > Why can't they just implement project files as text files and let you > > control them by hand? > > > > Regards > > Marc > > The 8.2 project navigator can still read the old text style .npl files. > If you > have a copy of 6.3 or older ISE you can see how these project files > look. > There is a caveat. When you open a .npl file from 8.2, ISE not only > converts the project to the new format and creates an .ise file, but > it also trashes the .npl file. So always keep another copy for > re-building > the project after a crash. > > HTH, > GaborArticle: 113551
On 14 Dec 2006 17:37:33 -0800, "Clay" <physics@bellsouth.net> wrote: (snipped) > >Hey Jerry, an IQ multiplier refers to the machine built by the Krell. >It was Dr. Mobius' undoing. > >Clay Hi Clay, Good God. Forbidden Planet. Possibly the single greatest science fiction movie *EVER* produced. (And that was BEFORE computer-generated graphics.) Anyone who saw that movie, back then, was "touched" by its grandeur, its thrills, its romance, its hope for the future, its profound message of human evil and human goodness. Ha ha. I should run out and rent the DVD of that movie tonight. See Ya', [-Rick-] Clay, ... Copyright Form :-)Article: 113552
Nevo wrote: > Mark, that's very interesting. I have a configuration device on my board, > but I'm not entirely sure that it's wired correctly. (I laid some traces on > the board wrong and hand-soldered the parts.) > > I'll spend some careful time reviewing this. Thank you for your > observations. > > Oddly, I don't see this mentioned in the cyclone datasheet. > > -Nevo > > "Mark McDougall" <markm@vl.com.au> wrote in message > news:457cfcd0$0$2704$5a62ac22@per-qv1-newsreader-01.iinet.net.au... >> Nevo wrote: >> >>> I have a board designed around the EP1C6 Cyclone device. The Quartus >>> programmer is able to detect the EP1C6 on a JTAG boundary scan. I'm able >>> to >>> initiate programming the device over the JTAG port, but Quartus gives me >>> an >>> error CONF_DONE failed to go high on device 1. >> Interesting that you have these problems... >> >> I have very recently inherited a board which I am using for a very >> different purpose to that for which it was originally intended. The >> board is based on an EP2C35 and has options for both passive and active >> serial configuration, as well as JTAG. The former options require >> configuration devices to be plugged into DIP sockets on the board. >> >> Not needing auto-configuration, I dispatched with the config devices (I >> actually don't *own* any) but was met with "CONF_DONE not going high" >> when attempting to configure via JTAG. >> >> After scratching my head for some time, I eventually tried it with the >> config device plugged in - and it worked! >> >> Now I can't for the life of me understand why this device must be >> present for JTAG programming? There's a pullup on CONF_DONE (10k)and >> nSTATUS (10k). >> >> What's more, at one stage I configured the FPGA then removed the config >> device whilst still powered - and I'm pretty sure a subsequent attempt >> to configure the FPGA via JTAG actually succeeded!?! >> >> Ultimately I need a solution because eventually I probably won't have >> access to the config device (it's on a small daughterboard) and I just >> don't like not knowing *why* it doesn't work!?! >> >> So any suggestions/insight/wild guesses would be most welcome here too! >> >> I guess I should add that CONF_DONE is being routed to an empty header >> (for ASM programming) and also an empty socket. >> >> Regards, >> >> -- >> Mark McDougall, Engineer >> Virtual Logic Pty Ltd, <http://www.vl.com.au> >> 21-25 King St, Rockdale, 2216 >> Ph: +612-9599-3255 Fax: +612-9599-3266 We don't use configuration devices on any of our FPGAs and have no problems configuring them from JTAG or a microcontroller. Check to make sure that you have pullups on nCONFIG, CONFIG_DONE, and nSTATUS. Passive serial configuration devices provide these pullups by default, which could be missing on the board. Removing the configuration device would remove the pullups, preventing configuration even from JTAG. MarcArticle: 113553
John Larkin wrote:
>
> I might modestly suggest that my little circuit shifts the DC level
> down, reduces the AC swing, terminates the differential trace
> impedance, furnishes the pecl pulldown current, and presents the same
> clean square wave to both fpga clocks, all independent of trace
> lengths.
>
One caution, most Xilinx LVDS inputs have a Cin of around 8-12 pF
(single ended), which will cause horrible {re}reflections when driven
directly in a multidrop topology from a fast ECL driver- unless those
MGT clock inputs have much better Cin than the regular LVDS inputs.
Given the physical size of an FX60 package, there's likely to be
enough distance between the two inputs to create a ledge or
double clock with both inputs hanging off of the same net like that.
The fanout buffer is probably the best solution, but if I had to make
it work driving two 10 pF inputs with internal Rterm from a single net,
I'd probably try series R's at each clock input to form a higher
impedance line tap/divider coupling a portion of the signal off of an
externally end-terminated net.
other related FPGA LVDS notes:
- Spartan 3E LVDS inputs have a much improved Cin of around 3 pF
- Xilinx common mode input range with internal terminations:
Although the LVDS inputs WITHOUT internal termination have
a wide common mode range, the internally terminated variants
(DIFF_TERM, DT) apparently are restricted to the much narrower
common mode range of the associated differential OUTPUT standard
to meet the specified internal termination tolerance
- resistive ECL level shifts for solitary FPGA LVDS inputs:
When driving a single LVDS input, I usually use something like
Fig. 15 of AN1568, which creates the shift with a tapped pulldown:
- http://www.onsemi.com/pub/Collateral/AN1568-D.PDF
Plus additional provision for a series Rs from each junction,
letting you tweak the back termination to match the line.
Those resistors can then all be placed right at the driver,
far, far away from the cluttered BGA breakout pattern, with
the typical LVDS 100 ohm Rdiff at the receiver input.
Brian
Article: 113554Has any one done netlist simulation . Virtex-4 FPGA . Power PC Based Architecture. Boot , Instruction and Data code resides on External SDRAM.( So using Power PC SWIFT or Smart model is ruled out). I am using (Coreconnect -PLB-BFM) for functional simulation. I need help regarding the netlist simulation . Regards SashArticle: 113555
Yes. In addition, please make good use of "RST_DEASSERT_CLK" and "EN_REL" when you are worry about phase. Ricky Austin Lesea wrote: > John, > > Yes. > > The PMCD is simply some D type flip flops, with a delay matched path for > the 1X output. If the phases of the divided clocks are important, then > reset of the PMCD is useful. If the phases are not important, don't > even bother with the reset of the PMCD. When the PCM input clock is > driven by the DCM, one should not worry about the reset, as you say, the > DCM will not do anything 'bad' to the PMCD while reset is asserted. > > Austin > > johnp wrote: > > In looking at the Virtex-4 documentation for the PMCD, Xilinx shows a > > simple > > connection from the DCM to the PMCD. They don't show the clocking for > > the > > reset signal going into the PMCD even though the Xilinx doc says that > > the > > reset should be released synchronously to with the clock. > > > > If the DCM and the PMCD both get the same reset signal, I assume that > > since the > > DCM output clocks should be stopped while reset is asserted, inherently > > the > > release of reset will be synchronous to the clock since the clock won't > > be running > > at the time. > > > > Does this match other people's understanding? > > > > Thanks! > > > > John Providenza > >Article: 113556
oen_br wrote: > Antti, > > I think he wanted to ask for the prices for the Spartan-3A. > I also could not find any prices for it. > > Luiz Carlos Hi Antii, oen_br Actually i really meant Virtex-5; Antii, i've seen the document you are saying but its price if for large volumes, about US$279 for the LX85 package. http://www.xilinx.com/prs_rls/2006/silicon_vir/0658lxship.htm (sorry for virtex-5 posts on spartan-3a thread). NetokoArticle: 113557
Netoko Young schrieb: > oen_br wrote: > > Antti, > > > > I think he wanted to ask for the prices for the Spartan-3A. > > I also could not find any prices for it. > > > > Luiz Carlos > > Hi Antii, oen_br > Actually i really meant Virtex-5; Antii, i've seen the document you > are saying but its price if for large volumes, about US$279 for the > LX85 package. > http://www.xilinx.com/prs_rls/2006/silicon_vir/0658lxship.htm > (sorry for virtex-5 posts on spartan-3a thread). > > Netoko :) correct document, but the prices there are "low volumes" actually large volumes would have been 100,000+ pieces AnttiArticle: 113558
I am trying to import a PowerPC design from EDK 7.1 to ISE 7.1 Project Navigator. While the design is working just fine when I download it from EDK, when I am trying to synthesize it in ISE and then download it to the FPGA nothing happens. It seems like the processor has no code to execute. In Project Navigator I generate the bitstream first and then I am updating the bitstream with processor data, just as the manual of the EDK mentions. Has anyone else the same problem?Article: 113559
Has anyone else seen the problem that lecroy7200@chek.com talks about when using a DCM to multiply an input clock to create the 200MHz input clock to the IDELAYCTRL block? My current design is planning to use a DCM to convert a 14.318MHz clock to a 200.4 MHz for the IDELAYCTRL clock. I don't want to fight problems with this if it is doomed to failure. Any suggestions on DCM + IDELAYCTRL ? Thanks! John Providenza lecroy7200@chek.com wrote: > I tried the same tests setting the DCM to D=1 M=4, D=2 M=8 and setting > the CLKIN_DIVIDE_BY_2 to TRUE then using D=1 and M=8. All seem to > cause problems with the IDELAYCTRL. > > I then took the RF generator (via the PECL driver) and used it to drive > the DCM. > > Running the RF generator at 200MHz and using the CLK0 to drive the > IDELAYCTRL appears to work fine (delay per tap seems correct). > > Running the RF generator at 50MHz and driving the DCM but using D=1 M=4 > and the CLKFX out does not seem to work. > > Running the RF generator at 100 MHz then using a D=1 M=2, CLKFX out > appears to work. > > Running the RF generator at 200 MHz then using a D=2 M=2, CLKFX out > appears to work. > > Austin had published a note about using a 66MHz clock with the DCM set > to D=1 M=3 and having it work. > > "The Ref Clock may be supplied from any +/- 10% 200 MHz source, > including > the DCM CLKFX output. For example, if there is a 66 MHz clock, a M=3, > D=1 will provide you with a ~ 200 MHz output on CLKFX. There is no > need > to be concerned with the jitter from the CLKFX, as the analog locked > loop which controls the delay is effectively a PLL which filters out > the > high frequency jitter components (jitter on Refclk is attenuated when > transfered to the data lines)." > > I tried this same test and it appears not to work (I see that same > 200pS / tap). > > It seems to be related to how many multiplier stages used in the DCM. > > Has anyone else seen this?Article: 113560
"johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag news:1166289684.160124.11030@l12g2000cwl.googlegroups.com... > Has anyone else seen the problem that lecroy7200@chek.com talks about > when using a DCM to multiply an input clock to create the 200MHz > input clock to the IDELAYCTRL block? > > My current design is planning to use a DCM to convert a 14.318MHz clock > to a 200.4 MHz for the IDELAYCTRL clock. I don't want to fight > problems > with this if it is doomed to failure. > > Any suggestions on DCM + IDELAYCTRL ? > > Thanks! > > John Providenza > hm I am testing with 2 different DDR2 designs, using either 100 or 50 mhz input clock the 200mhz for idelayctrl is derived from second DCM first dcm FX is used to get internal 200mhz both designs seem to work somewhat, there are some problems but those are more likely fpga timing or board layout related. in any case fx=200 from 50mhz input does work, eg memory tests on the DDR2 memory do pass all. AnttiArticle: 113561
Vangelis schrieb: > I am trying to import a PowerPC design from EDK 7.1 to ISE 7.1 Project Navigator. While the design is working just fine when I download it from EDK, when I am trying to synthesize it in ISE and then download it to the FPGA nothing happens. It seems like the processor has no code to execute. In Project Navigator I generate the bitstream first and then I am updating the bitstream with processor data, just as the manual of the EDK mentions. Has anyone else the same problem? you may not like the answer but 1) DO NOT try to use import-export from EDK 2) use only latest major release, eg 8.1 but 8.2 preffered 1 create ISE project 2 add the XMP file 3 click "update bitstream with processor data" from ISE and you get it all initialized and working AnttiArticle: 113562
On 2006-12-15, jerzy.zielinski <jerzy.zielinski@gmail.com> wrote: > Can anyone help me with the bootloader, so the whole project may start > after power-on? I need to place the system.bit and linux core somewhere > on the board so it may boot by itself... If you make a zImage, you only have to jump to it and it will relocate itself to the location it was built for. It can even handle overlapping with the destination. If you have that image in flash, you could memory map the flash and jump into it, or you could pump it out into RAM (anywhere) and jump into it. What do you have mapped at the reset vector 0xfffffffc? Flash? Block RAM? -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 113563
John <seabass950@yahoo.com> wrote: > Is there a mindelay constraint keyword or something similar? > My fpga is producing 1 byte with a clock signal going to the > pads and I need the data to be on the pads for 5ns, then clock. > So I just need a way to delay the clock until data is definitely ready. If the data is there for a whole cycle the easy way is to latch it on the opposite clock edge. That should be near the middle of the clock cycle. If that doesn't work, try the other suggestions. -- glenArticle: 113564
Did you post this three times by intention :-) ? Well I also had problems with projects. The only thing to do: Snap Shots and manual archives with Winrar.Article: 113565
I am still using 8.1sp3 (project constraints), and I generally work around this bt creating a batch file which calls ngdbuild, map, par, etc. in turn. The batch file is based on the log file created from the initial run with the project file. Jason "marc_ely" <marc_ely@yahoo.co.uk> wrote in message news:1166196746.946286.260300@n67g2000cwd.googlegroups.com... > Hi > > A couple of months ago I had to move up to ISE 8.2 once 7.1 stopped > meeting my timings. Since I moved I have had nothing but problems with > project files and their corruption. > I have finally settled on 8.2.3 as it appeared more stable than older > patched versions. 8.2.0 was dire. > > The project file corruptions seem to occur randomly and will do various > things, such as remove all files from the project (and not let you add > them back), or not let you edit coregen parts, or a host of other > things. > > Re-creating a project each time seems very laborious. Does anyone have > any shortcuts to do this? Is there a TCL script that can be run? > Archiving and Project Cleanup don't help. > > The project is a mix of VHDL, verilog and coregen parts (xaw and xco). > > Why can't they just implement project files as text files and let you > control them by hand? > > Regards > Marc >Article: 113566
In article <1166196746.946286.260300@n67g2000cwd.googlegroups.com>, marc_ely <marc_ely@yahoo.co.uk> wrote: > The project file corruptions seem to occur randomly and will do various > things, such as remove all files from the project (and not let you add > them back), or not let you edit coregen parts, or a host of other > things. > > Re-creating a project each time seems very laborious. Does anyone have > any shortcuts to do this? Is there a TCL script that can be run? > Archiving and Project Cleanup don't help. In general: a) Use a good version control system, such as CVS or SVN, and then revert to a good version whenever you run into corruption or b) Save a copy of the project when it is working, and then copy it back when things stop working. a) is what you should do. b) is what you will do now that I've suggested it. a) is what you will eventually do. > Why can't they just implement project files as text files and let you > control them by hand? Because they haven't yet learned the lesson that ISE designers tend to learn eventually. Text file project definitions always rise to the top of the users' wish list eventually, even though it is initially easier for the tool developers to just write() the binary structures into a file. -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 113567
Hi, I am going to start a project of onboard high-speed CMOS image processing. I am goint to perform certain *block matching algorithm* or *Fourier Transform* between successive frames and the fps would be 1000 or more.. The interface between the CMOS camera and the board is standord CamLink. I've learned that both DSP and FPGA based circuits can do certain onboard image processing tasks, and I'd like to know whick is better? DSP or FPGA? I know some corporations use FPGA based boards as development boards for their cameras. And my cooperators have some DSP development experiences. So, the question arises, and I want your suggestions. I'd like to know the advantages of each choise and maybe the direction of onboard realtime high-speed image processing. Thanks! Any help would be appreciated.Article: 113568
I need to divide my clock by 10, can someone confirm
if my verilog module will work:
//divide oscillator clock by 10 (xc9536)
module clk_div10 (in,out)
input in;
output out;
reg[0..3] cnt;
always @ (in)
begin
cnt=cnt+1;
if (cnt ==10)
begin
cnt =0;
out =out +1;
end
end
endmodule
Article: 113569
Correction, this is wrong
out =out +1;
Put this in instead
out =!out
Article: 113570
222 wrote:
> I need to divide my clock by 10, can someone confirm
> if my verilog module will work:
>
> //divide oscillator clock by 10 (xc9536)
> module clk_div10 (in,out)
> input in;
> output out;
> reg[0..3] cnt;
> always @ (in)
> begin
> cnt=cnt+1;
> if (cnt ==10)
> begin
> cnt =0;
> out =out +1;
> end
> end
> endmodule
>
>
The short answer is 'NO'
I can see a few issues. Do you need a 50% duty cycle on the output
clock? That would bring up another issue.
I'll be generous and assume this is not homework, but if it is, realise
you're not really learning anything if you don't make your own mistakes;
that way the lesson sticks ;)
//divide oscillator clock by 10 (xc9536)
module clk_div10 (in,out)
input in; // input clock
output out; // output clock = input/10
reg[0..3] cnt;
assign out = cnt[3]; // map MSB to output - previous code
needed a // reg
// statement, which may or may not have
// been absorbed.
// always @ (in)
always @ (posedge in) // use the edge. The previous statement
was a //static sensitivity list, as used in
// combinational assignments
begin
// cnt=cnt+1; // let's not use a blocking assignment
if (cnt[3] & (cnt[2:0])) // test for increment or // reset at top
begin
cnt <= 4'b0; // count == 9 normally, and also //guarantees
// to move the counter to a valid state if it
// somehow was in the range of 10 - 15
// Also need to tell some tools explicitly
// about the number of 0s
// I also added a little trickery to the test
// which you will need to understand if you are
// presenting this as homework ;)
end
else begin // just increment
cnt <= cnt+1;
end
end
endmodule
I did a number of things, as you can see - now figure out why :)
If you want a 50% duty cycle, it's a different matter.
Cheers
PeteS
Article: 113571PeteS wrote: > 222 wrote: >> I need to divide my clock by 10, can someone confirm >> if my verilog module will work: >> >> //divide oscillator clock by 10 (xc9536) >> module clk_div10 (in,out) >> input in; >> output out; >> reg[0..3] cnt; >> always @ (in) >> begin >> cnt=cnt+1; >> if (cnt ==10) >> begin >> cnt =0; >> out =out +1; >> end >> end >> endmodule >> >> > The short answer is 'NO' > > I can see a few issues. Do you need a 50% duty cycle on the output > clock? That would bring up another issue. > > I'll be generous and assume this is not homework, but if it is, realise > you're not really learning anything if you don't make your own mistakes; > that way the lesson sticks ;) > > > //divide oscillator clock by 10 (xc9536) > module clk_div10 (in,out) > input in; // input clock > output out; // output clock = input/10 > reg[0..3] cnt; > > assign out = cnt[3]; // map MSB to output - previous code needed > a // reg > // statement, which may or may not have > // been absorbed. > // always @ (in) > always @ (posedge in) // use the edge. The previous statement was > a //static sensitivity list, as used in > // combinational assignments > begin > // cnt=cnt+1; // let's not use a blocking assignment > // > if (cnt[3] & (cnt[2:0])) // test for increment if (cnt[3] & (&cnt[2:0])) // test for increment - fixed > or // reset at top > begin > cnt <= 4'b0; // count == 9 normally, and > also //guarantees > // to move the counter to a valid state if it > // somehow was in the range of 10 - 15 > // Also need to tell some tools explicitly > // about the number of 0s > // I also added a little trickery to the test > // which you will need to understand if you are > // presenting this as homework ;) > end > else begin // just increment > cnt <= cnt+1; > end > end > endmodule > > > I did a number of things, as you can see - now figure out why :) > > > If you want a 50% duty cycle, it's a different matter. > > Cheers > > PeteS One fix in the test - more coffee!!!Article: 113572
There is a simple way of avoiding "mysterious glitches" when using binary counters: freeze the counter in a second register in the first clock domain and do a one bit handshake across the two domains. Since the counter (copy) is frozen during the handshaking, the other clock domain's FFs will have ample setup time until the strobe propagates through the resync. With a fully resync'd handshake, this approach does introduce up to 3x clock1 + 1.5x clock2 cycles delay between update, which is certainly not suitable for low-latency and small high-speed FIFOs, especially if there is a large difference in clock speeds. It works well as long as one can live with long status delays for the first (read) and last (write) few FIFO words. The design is nice as long as clocks are of similar frequencies but the delay may become an issue for large read:write (and vice-versa) clock ratios. At 10:1, the status update may have a latency exceeding 40 fast clock cycles. So, binary counters can be safely used by using frozen copies and handshaking. The caveat is higher latency than gray counters due to handshaking and register copies that add extra dependencies upon the other clock domain. As always, designers are free to pick their poison. Peter Alfke wrote: > In an asynchronous FIFO, reading and writing is controlled by two > counters with independent clocks. > If you need to detect FULL or EMPTY, you compare the two counters for > identity. > If you do that with binary counters, you are vulnerable to strange > decoding glitches, while multiple binary bits change (almost, but not > quite, simultaneously). You never have that problem with Gray counters, > where only one bit changes, from one state to the next. > Peter Alfke > ============= > RCIngham wrote: >>> There is a wrong way and a right way to convert binary to Gray count >>> values: >>> The wrong way hangs the (simple!) combinatorial conversion logic (XORs) >>> on the binary outputs. That does you no good, since the Gray code will >>> just reflect the binary transient errors. >>> The right way takes the D inputs of the binary counter (, converts them >>> independently to Gray and registers them in their own flip-flops. Now >>> you have two parallel rgisters, both counting in step, the first in >>> binary, the other in Gray, and there are no funny decoding spikes. >>> BTW, only Gray counter outputs have the feature that you can compare >>> two asynchronous counters for identity, without transient errors. >>> If the Gray code does not come from a counter, it might change multiple >>> bits per transition... >> <snip /> >> Whether that is the right answer rather depends on WHY the OP "has" to use >> Gray Code, which is still not fully established. >> >> BTW, there is a quite interesting article on Gray Code just posted at: >> http://www.pldesignline.com/showArticle.jhtml?articleID=196604078 >Article: 113573
222 wrote: > Correction, this is wrong > out =out +1; > Put this in instead > out =!out > > Since you toggle "out" every time your counter reaches 10, you are actually creating a waveform with twice the period you intended. Also, because counting starts at 0 and you compare with 10, there are actually 11 counts between toggles instead of 10. So, unless I am mistaken (I have not touched verilog much, everything I have worked on so far has been in VHDL), your code would be dividing the clock by 22 instead of 10, assuming it is otherwise functional.Article: 113574
> > Correction, this is wrong > > out =out +1; > > Put this in instead > > out =!out > > > > > > Since you toggle "out" every time your counter reaches 10, you are > actually creating a waveform with twice the period you intended. Also, Does "always @(x)" work on _any_ change, i.e. it should react twice on each clock, which would make it right, or does it default to positive edge, which would make it twice the period? > because counting starts at 0 and you compare with 10, there are actually > 11 counts between toggles instead of 10. Correct, I need to count to 9. > > So, unless I am mistaken (I have not touched verilog much, everything I > have worked on so far has been in VHDL), your code would be dividing the > clock by 22 instead of 10, assuming it is otherwise functional.
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