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
Hi. I have the following situation, it is a bit complicated to explain but I hope I can make myself clear. - I have a board (called S1) with an FPGA on it, and other stuff (microcontroller, many connectors, memory, etc...). The only thing I think it is useful to know for you, is that I have access to the FPGA via USB cable. - In another board (called S2) I have an ASIC chip to test. At the present time, I'm able to load a simple bitstream (generated using Xilinx ISE environment) on the FPGA. I can load this bitstream because someone wrote a simple driver to control the FPGA, so I can just start the program, press a "browse" button to select the bitstream and press the "upload" button to load the bitstream. In the next days, I have to write a simple Verilog code to provide signals to the FPGA (like token, trigger, etc...not important). Given these signals, the chip has to perform some operation, and it gives me an output. The output is a serial data of 48 bit. Here start the problems: - I have to store the data somewhere in the FPGA, so I was thinking that I could create some RAM (using the Core Generator for example) and then store the data inside these kind of register. - Then, I have to read out the FPGA. To do this, I have a C++ header file with some functions in it, that I can use to read out the data. Questions: - do you think that the RAM solutions is ok? are there any better ways to store the data? - is there another way to read out the chip? I mean, suppose I don't have the C++ functions, is it still possible to read the data arriving at a certain pin of the FPGA? I think it should be possible, but at the moment I have no idea how to do this. Moreover, I need to store these data in a file...I guess this should be possible too. I know that the problem is quite general but if you could give me some guidelines I would really appreciate it, so at least I know what I have to search for. Thank you for any help Francesco.Article: 144276
Hi, I'm hoping someone can help me! I'm part of a group doing an amateur radio satellite project (KiwiSAT). We have a bug in some logic in the above Quicklogic device. Due to ITAR the guys that initially developed this logic cannot help with the bug fix or programming a device. We don't have access to the tools (Quickworks I think) or the programmer. Can anyone outside the US help us with the SW tools and the use of a programmer for this (now obsolete) device! We may have found a supply of the part, but if anyone can help here also it would be great! Regards ClaytonArticle: 144277
On Nov 18, 7:19 pm, "John Speth" <johnsp...@yahoo.com> wrote: > Hi folks- > > I'm in the beginning stages of crafting a high-speed measurement device > which needs to output a floating point value in ASCII string form that > represents the measurement at a rate of 10 kHz. I'm using an Altera FPGA > that runs Nios2. Convenient standard library functions like sprintf() or > ftoa() running as code will be too time-consuming to meet my high throughput > requirements. What I need is an ultrafast float to ASCII conversion > function that can run in code *or* a strategy for implementing a conversion > function in HDL. Altera has a nice tool called C to HDL compiler which I'm > looking at now. > > It seems to me that a fast float to ASCII conversion function would be a > common function of many embedded systems. Rather than me reinventing the > wheel, can anyone point me to a resource (example on the web or a product > for sale) that I can use to achieve my goal? > > Thanks, John Speth. It seems your task not just doesn't require floating-point to ASCII conversion, it needs no floating point at all. I'd go as far as to say that even if there was fast floating point hardware I'd still prefer to not use it for that type of task. Use fix point! Suppose, you have 14-bit ADC with 3V unipolar scale and you want to present the result in mV with three digits after decimal point. All you need to do is something like: const int ADC_CODE_TO_uV_NUM = int(3E6); const int ADC_CODE_TO_uV_DEN = 1<<14; unsigned result_uV = (unsigned)(((long long)result_code * ADC_CODE_TO_uV_NUM*2 + ADC_CODE_TO_uV_DEN)/(ADC_CODE_TO_uV_DEN*2)); char result_uV_str[32]; int len1 = siprintf(result_uV_str, "%04u", result_uV); char result_mV_str[32]; memcpy(result_mV_str, result_uV_str, len1 - 3); result_mV_str[len1 - 3] = '.'; memcpy(&result_mV_str[len1 - 3 + 1], &result_uV_str[len1 - 3], 3); result_mV_str[len1 + 1] = 0;Article: 144278
Hi there, I have a question regarding clock deskewing. My design has a sub module that gets its clock signal from a regional clock pin, however, the clock skew is too large and causing timing violations. I read about something on DCM and thought about using it to deskew this regional clock, but it seems to me that DCM can only be used in conjunction with global clock lines. The board layout is fixed, which means no way I can use a global clock line for this signal, have to live with it. Has anybody experience with regional clock deskewing? Thanks a lot!Article: 144279
Alexey <trenkoff@gmail.com> writes: > Hello, > > I need to connect two Microblaze processors, each on a seperate > Spartan 3e chip, but on the same board. Can this be done through FSL? > Would it require two seperate projects in the XPS? Is there an example > or tutorial on this subject? To add to Austin's suggestions, a simple UART link would be very easy if the bandwidths are low. Two pins (crossed over :) and simple software. However you do it, you would need two projects in XPS, unless there is enough commonality in the peripherals and pinouts that you could make one bitstream do the whole job for both FPGAs. I doubt you'll find much in the way of examples - multiprocessor systems with microblazes in separate chips are a bit thin on the ground! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 144280
On Nov 24, 8:07=A0am, bonnerfme <xiaoling...@fme.fujitsu.com> wrote: > Hi there, > > I have a question regarding clock deskewing. My design has a sub > module that gets its clock signal from a regional clock pin, however, > the clock skew is too large and causing timing violations. > > I read about something on DCM and thought about using it to deskew > this regional clock, but it seems to me that DCM can only be used in > conjunction with global clock lines. The board layout is fixed, which > means no way I can use a global clock line for this signal, have to > live with it. > > Has anybody experience with regional clock deskewing? > > Thanks a lot! Are you sure you mean deskew? That is a routing issue. I don't see how a DCM would help unless you're talking about the skew between the regional clock and some other clock. Confused, GaborArticle: 144281
On Tue, 24 Nov 2009 03:16:23 -0800 (PST), Claytong_nz wrote: >I'm part of a group doing an amateur radio satellite project >(KiwiSAT). We have a bug in some logic in the above Quicklogic device. >Due to ITAR the guys that initially developed this logic cannot help >with the bug fix or programming a device. We don't have access to the >tools (Quickworks I think) or the programmer. Can anyone outside the >US help us with the SW tools and the use of a programmer for this (now >obsolete) device! >We may have found a supply of the part, but if anyone can help here >also it would be great! I have a programmer I could lend/sell, and a few 12x16 84-pin parts (no 68-pin or 8x12 AFAIK, but you could easily make up an adapter). I may also be able to dredge up an archived copy of the tools, but they ran under Win3.1 so you may need a museum-piece PC to use them. And of course there's the small difficulty of 12,000 miles between you and me :-) It might be better for you to get some small modern CPLD and emulate, rather than replace, the old QL8x12. They were cute little parts but there's not much logic in 'em (only 96 FFs and associated AND/MUX logic, right?) so even a modest CPLD should do the job. And you may still be able to find CPLDs with 5V I/O, which is likely to be your most troublesome stumbling block. -- Jonathan BromleyArticle: 144282
a, The DCM has a fixed phase shift feature, so you can "move" the clock outputs, anywhere you want, from 0 to 360 degrees, with 1/256 resolution. AustinArticle: 144283
Jonathon, CPLDs will fry themselves in space (latchup and die). This is well known in the aerospace community: do not put a CPLD in space! de AB6VU (Austin)Article: 144284
On Tue, 24 Nov 2009 07:47:47 -0800 (PST), austin <austin@xilinx.com> wrote: >Jonathon, > >CPLDs will fry themselves in space (latchup and die). > >This is well known in the aerospace community: do not put a CPLD in >space! OK, didn't realize he was planning to fly the thing :-) -- JonathanArticle: 144285
On Nov 24, 2:49=A0pm, Gabor <ga...@alacron.com> wrote: > On Nov 24, 8:07=A0am, bonnerfme <xiaoling...@fme.fujitsu.com> wrote: > > > Hi there, > > > I have a question regarding clock deskewing. My design has a sub > > module that gets its clock signal from a regional clock pin, however, > > the clock skew is too large and causing timing violations. > > > I read about something on DCM and thought about using it to deskew > > this regional clock, but it seems to me that DCM can only be used in > > conjunction with global clock lines. The board layout is fixed, which > > means no way I can use a global clock line for this signal, have to > > live with it. > > > Has anybody experience with regional clock deskewing? > > > Thanks a lot! > > Are you sure you mean deskew? =A0That is a routing issue. =A0I don't > see how a DCM would help unless you're talking about the skew > between the regional clock and some other clock. > > Confused, > Gabor Hi Gabor, you're right, this is a routing issue.I meant the skew just on this regional clock, not the skew between it and some other clock. Maybe DCM is not the right thing to go for, I'm no sure, please advise what is the correct thing I should look into. BRArticle: 144286
bonnerfme wrote:
> My design has a sub
> module that gets its clock signal from a regional clock pin, however,
> the clock skew is too large and causing timing violations.
You could make a synchronous divide by n +- cal ppm
using a phase accumulator. A host computer
could do the time error to delta cal calculation
if the integrated time error can be measured.
-- Mike Treseler
Article: 144287input violations, output violations, or flop/flop violations? Is your clock being routed using logic routing resources or a dedicated clock resource? Your clock needs to go on a global clock line if it isn't there already. It's hard to meet timing with clocks on logic routing, maybe with some careful hand placement you could do it. --steve "bonnerfme" <xiaoling.li@fme.fujitsu.com> wrote in message news:3a29c0c0-14cf-4289-92ee-aaf972ef2af7@t18g2000vbj.googlegroups.com... : Hi there, : : I have a question regarding clock deskewing. My design has a sub : module that gets its clock signal from a regional clock pin, however, : the clock skew is too large and causing timing violations. : : I read about something on DCM and thought about using it to deskew : this regional clock, but it seems to me that DCM can only be used in : conjunction with global clock lines. The board layout is fixed, which : means no way I can use a global clock line for this signal, have to : live with it. : : Has anybody experience with regional clock deskewing? : : Thanks a lot!Article: 144288
On Nov 24, 12:31=A0pm, bonnerfme <xiaoling...@fme.fujitsu.com> wrote: > On Nov 24, 2:49=A0pm, Gabor <ga...@alacron.com> wrote: > > > > > On Nov 24, 8:07=A0am, bonnerfme <xiaoling...@fme.fujitsu.com> wrote: > > > > Hi there, > > > > I have a question regarding clock deskewing. My design has a sub > > > module that gets its clock signal from a regional clock pin, however, > > > the clock skew is too large and causing timing violations. > > > > I read about something on DCM and thought about using it to deskew > > > this regional clock, but it seems to me that DCM can only be used in > > > conjunction with global clock lines. The board layout is fixed, which > > > means no way I can use a global clock line for this signal, have to > > > live with it. > > > > Has anybody experience with regional clock deskewing? > > > > Thanks a lot! > > > Are you sure you mean deskew? =A0That is a routing issue. =A0I don't > > see how a DCM would help unless you're talking about the skew > > between the regional clock and some other clock. > > > Confused, > > Gabor > > Hi Gabor, you're right, this is a routing issue.I meant the skew just > on this regional clock, not the skew between it and some other clock. > Maybe DCM is not the right thing to go for, I'm no sure, please advise > what is the correct thing I should look into. > > BR What kind of device are you using? Is this "Regional clock" driven by a dedicated clock buffer like a BUFR in the Virtex 5? Or do you mean you're using non-global routing resources for the clock?Article: 144289
>> The CH7301 required exact waveforms on the H, V & DE pins (I chose VGA >> mode 0, 640x480), otherwise the display wouldn't sync. I went for >> "sample 2x", i.e. XCLK and XCLK* toggle with 25 MHz, phase shifted by >> 180 deg. Guess proper XCLK/XCLK* clocking is essential to sample H, V >> and DE. > > Does "VGA mode 0" refer to the IDF bits? Also, did you just choose 25MHz > randomly because it was less than 36MHz as Table 2: DVI Outputs in the > CH7301 datasheet says? With mode 0 I was referring to the standard VGA mode 640x480 @ 60 Hz. That's not related to any CH7301 settings, though The 25 MHz is the pixel clock for this mode (25.175 MHz to be precise). Also see http://tinyvga.com/vga-timing/640x480@60Hz In general, my strategy to get a color bar test pattern was to operate the CH7301 as if it was used to output image data: Configure and drive the chip as in the final application, just without video data applied. I guess the chip won't "do anything for you" except sketching colorful bars. You need to provide framing, sync timing etc. yourself. >> I2C commands were applied according to AN-41, "Figure 4: Single Step >> Writes". I.e. n times the sequence, SPC @ ~195 kHz: > > Was 195Khz a random choice of speed as well? Yes, a frequency within the respective CH7301 spec (it's 25 MHz / 128). > Did you have to write custom VHDL to do the timings for the V and H pins? Yes, a set of counters to generate H & V sync signals plus DE. The CH7301 embeds the horizontal and vertical sync information in the DVI stream under control of DE. I assume that the color pattern test mode simply fills in the display information but requires framing from external. BTW after some experimenting I went for the ODDR2 double data rate output registers for XCLK/XCLK* and video data and used the clock-vs-data phase shift feature for the CH7301. Alternatively, one could trim the video data outputs vs XCLK with DLL resources on the FPGA. > Did you use the 25MHz clock you chose above and the chosen resolution of > 640x480 to determine the H and V input lines? Again, yes. 25 MHz is the pixel clock frequency and it's used to generate the sync waveforms on H, V & DE. The same way as for VGA monitors/displays: H sync, V sync - DE is esentially the blanking signal covering also the front and back porches around active sync. > Does having the H and V > active low mean that the "active time" for outputting RGB values is when > you drop these signal lines? The VGA mode requires negative polarity on these lines, therefore I set this configuration and generated active low waveforms on the pins accordingly. Video data is accepted by the CH7301 when DE is 1. DE needs to be 0 to mux the H and V waveforms into the DVI stream. > I know there are lots of questions here and thanks for your help so far, I > don't know why there isn't better documentation for implementing this > chip... You're welcome :-) I had quite some headaches as well when struggling with this chip (and the docs). Once it's set up, fine. But until then the docs don't give you much clue how to start with it. The DVI spec http://www.ddwg.org/lib/dvi_10.pdf (especially chapter 3) was helpful. It clarified some of background topics like the meaning of DE. ArnimArticle: 144290
Hi guys,
I'm trying to generate a clock signal that can be switched between
16MHz, 8MHz and 4MHz, and have a 50% duty cycle (for a data separator/
slicer). Just to make this difficult, I only have a 40MHz master clock to
work from... which only has an even integer factor for 4MHz (divide-by-
ten). Divide-by-five gets 8MHz, but doesn't give a 50:50 ratio. 16MHz
isn't even possible (nearest I can get is 20MHz with a divide-by-two).
This is on an Altera Cyclone II 2C20, FBGA484 package, on a Terasic DE1
(actually Altera Cyclone II Starter Board, but the Terasic board is
essentially identical) development board. Software is Quartus 9.0.
Originally, this seemed like a simple problem to solve -- create a PLL
to generate a new set of clocks that were phase-locked to the original
40MHz master clock. Problem is, while I can get the PLL to generate a
16MHz clock, it won't go any lower -- 8MHz and 4MHz produce an alert to
the effect of "division ratio not possible."
So I figured I'd go about this a different way -- generate a 16MHz
clock with the PLL, then divide it down to 8MHz and 4MHz with a pair of
DQ flip-flops wired to toggle (or a binary counter, whatever worked).
This worked fine when I tied the outputs of the clock divider straight to
the clock input on the data separator.
This is what I have now:
// Instantiate a PLL to convert from 40MHz to 32MHz
wire CLK_PLL16MHZ;
DatasepClockGen dscg(CLK40MHZ, CLK_PLL16MHZ);
// Divide down the 16MHz reference to get 8MHz and 4MHz
reg CLK_PLL8MHZ;
always @(posedge CLK_PLL16MHZ) CLK_PLL8MHZ = ~CLK_PLL8MHZ;
reg CLK_PLL4MHZ;
always @(posedge CLK_PLL8MHZ) CLK_PLL4MHZ = ~CLK_PLL4MHZ;
wire DATASEP_MASTER_CLK;
assign DATASEP_MASTER_CLK = CLK_PLL4MHZ;
// Data separator
wire SHAPED_DATA, DWIN;
DataSeparator _datasep(DATASEP_MASTER_CLK, FD_RDDATA_IN,
SHAPED_DATA, DWIN);
// For debugging -- REMOVEME!
assign debug[3:0] = { DATASEP_MASTER_CLK, FD_RDDATA_IN,
SHAPED_DATA, DWIN };
debug[3:0] is a set of output pins, CLK40MHZ is the master clock,
CLK_PLL16MHZ is the output from the PLL. I can post the data separator
logic as well, but it's basically a Verilog implementation of the circuit
shown here:
<http://www.analog-innovations.com/SED/FloppyDataExtractor.pdf>
And this works fine on its own. I'm aware that there are issues with
glitches if I just use a straight multiplexer to switch between clock
sources, so I'm using the parameterised "clock_mux" module from the
Quartus manuals
(<http://www.altera.com/literature/hb/qts/qts_qii51007.pdf>, chapter 6,
page 48-50). I added it to my code like this (replacing the
DATASEP_MASTER_CLK assignments in the code above):
// Mux the clock
wire DATASEP_MASTER_CLK;
// Clock multiplexer
wire [3:0] datasep_clock_selects = {
(ACQCON_MFM_CLKSEL == 2'b00),
(ACQCON_MFM_CLKSEL == 2'b01),
(ACQCON_MFM_CLKSEL == 2'b10),
(ACQCON_MFM_CLKSEL == 2'b11) };
wire [3:0] datasep_clocks = {
(CLK_PLL16MHZ), // 3.5in ED (1Mbps)
(CLK_PLL8MHZ), // 3.5in HD (500kbps)
(CLK_PLL4MHZ), // 3.5in DD (250kbps)
(CLK_PLL4MHZ) }; // Dummy entry for SEL=0b11
clock_mux #(.num_clocks(4)) _datasep_clock_mux(
datasep_clocks,
datasep_clock_selects,
DATASEP_MASTER_CLK
);
This results in a ton of timing violation warnings from the timing
analyser, the most notable being these two:
Warning: Can't achieve minimum setup and hold requirement
DatasepClockGen:dscg|altpll:altpll_component|_clk0 along 9 path(s). See
Report window for details.
Critical Warning: Timing requirements for slow timing model timing
analysis were not met. See Report window for details.
Obviously the setup/hold violation is not a "Good Thing (tm)" and it
needs resolving ASAP (assuming the design works at all as it is). The
question is, how should I go about doing this?
I can replace the clock multiplexer with a straight AND/OR multiplexer,
which seems to resolve the timing issue (or it did last time I tried it),
but this risks causing glitching issues (although the Datasep should
reset within about 64 clock cycles).
Can anyone suggest a possible solution? This is driving me nuts...
probably because the errors from Quartus are about as clear as a pool of
mud, and it seems the Quartus "help" file is only serving to make the mud
thicker...
Thanks,
--
Phil.
usenet09@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "09" with the last two digits of the current
year.
Article: 144291The solution is so simple it is not even funny. 1. clk_40Mhz => PLL => clk_32Mhz 2. clk_32Mhz => binary counter => (clk_4Mhz, clk_8Mhz, clk_16Mhz) 3. (clk_4Mhz, clk_8Mhz, clk_16Mhz) => regular mux (do not use clock_mux!) => clk_temp 4. clk_temp => DFF with clk=clk_32Mhz => clk_outArticle: 144292
> So I figured I'd go about this a different way -- generate a 16MHz > clock with the PLL, then divide it down to 8MHz and 4MHz with a pair of > DQ flip-flops wired to toggle (or a binary counter, whatever worked). Noooooooo. Generate your 16 MHz clock then use this to drive everything with enable signals to give 8 and 4 MHz. You're then just selecting the active enable signal to get the clock you want. All nice and synchronous, don't generate ripple clocks etc. Nial.Article: 144293
On Nov 25, 3:56=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Tue, 24 Nov 2009 07:47:47 -0800 (PST), austin <aus...@xilinx.com> > wrote: > > >Jonathon, > > >CPLDs will fry themselves in space (latchup and die). > > >This is well known in the aerospace community: =A0do not put a CPLD in > >space! > > OK, didn't realize he was planning to fly the thing :-) > -- > Jonathan Thanks Jonathan, These FPGAs are apparently okay in low earth orbit. My understanding is that they are already up there and working fine - at least the older technologies such as this part (the rule for this project seems to be that unless it is obsolete we won't use it). Retrofitting a new device would not be the way to go! Our design is based on an existing (and in orbit) design, but we are now hand-tied by ITAR - hence the US guys are not permitted to help us. The PCB is all done but we've found this bug in the CPLD, so selecting a different one is not an option. The part is the 68pin PLCC. I'll follow up other leads, but if you are still willing and able I'd like to take you up on your programmer offer (or possibly purchasing it). Possibly I'll see if I can get someone from the amateur radio statelite community that is closer to you to assist. BTW, where are you? Regards ClaytonArticle: 144294
On Wed, 25 Nov 2009 03:30:36 -0800 (PST), Claytong_nz wrote: >These FPGAs are apparently okay in low earth orbit. My understanding >is that they are already up there and working fine - at least the >older technologies such as this part yeah, I guess they are fairly bulletproof (antifuse, 0.18um, ...) >now hand-tied by ITAR - hence the US guys are not permitted to help sheesh! >I'd like to take you up on your programmer offer I'd be happy to see it go to a good home; I don't see myself ever using it again. You get three or four 12x16B 84PLCC thrown in :-) And I'll try to find my archived copy of the software, but no promises on that; I haven't used it for years. > (or possibly purchasing it) Nah, you can have it - but we need to find a shipment method that doesn't cost me anything, and doesn't cost you very much. >BTW, where are you? Oxford, England - but working in Munich, Germany for much of the next few weeks. -- Jonathan Bromley, Verification Engineer Verilab www.THAT_COMPANY.comArticle: 144295
On Wed, 25 Nov 2009 01:51:00 -0800, Michael S wrote: > The solution is so simple it is not even funny. 1. clk_40Mhz => PLL => > clk_32Mhz > 2. clk_32Mhz => binary counter => (clk_4Mhz, clk_8Mhz, clk_16Mhz) 3. > (clk_4Mhz, clk_8Mhz, clk_16Mhz) => regular mux (do not use clock_mux!) > => clk_temp > 4. clk_temp => DFF with clk=clk_32Mhz => clk_out That works about as well as my original code... // Instantiate a PLL to convert from 40MHz to 32MHz wire CLK_PLL32MHZ; DatasepClockGen dscg(CLK40MHZ, CLK_PLL32MHZ); // Divide down the 32MHz reference to get 16MHz, 8MHz and 4MHz reg [2:0] DatasepClkDiv; always @(posedge CLK_PLL32MHZ) DatasepClkDiv <= DatasepClkDiv + 1; // Clock multiplexer reg DATASEP_CLK_pre; always @(ACQCON_MFM_CLKSEL or DatasepClkDiv) begin case (ACQCON_MFM_CLKSEL) 2'b00: DATASEP_CLK_pre = DatasepClkDiv [0]; 2'b01: DATASEP_CLK_pre = DatasepClkDiv [1]; 2'b10: DATASEP_CLK_pre = DatasepClkDiv [2]; default: DATASEP_CLK_pre = DatasepClkDiv [0]; endcase end // Sync clock against 32MHz master clock to remove glitches reg DATASEP_MASTER_CLK; always @(posedge CLK_PLL32MHZ) DATASEP_MASTER_CLK <= DATASEP_CLK_pre; produces: Warning: Can't achieve minimum setup and hold requirement DatasepClockGen:dscg|altpll:altpll_component|_clk0 along 1 path(s). See Report window for details. Critical Warning: Timing requirements for slow timing model timing analysis were not met. See Report window for details. So the same problem as before, basically... Thanks, -- Phil. usenet09@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "09" with the last two digits of the current year.Article: 144296
hello, I woud like to design a 32,768 Hz stable input for calibrated real-time operation of a FPGA-centric system, as power-of-two frequencies make digital computations very easy, using shifts instead of divides for motion equations. * I "could" use a multiple of this frequency as my main clock but I find no suitable canned oscillator (a 3.3V 5x7mm one is preferred, cheaper is better) examples : - 18.423MHz / 32768 = 562.5 => almost there... so I would have to divide it by 5*5*5*3*3 to get a power-of-two frequency, but only 16KHz. - 24.576MHz (close to my target 25MHz) = 2*3*5*5*5 * 32768 so I get a nice 65536Hz after 4 small prescalers but my other 25MHz circuits won't be happy by 1.7%. And I have already bought the 25MHz oscillators :-/ * I "could" make a custom oscillator with a cheap&tiny "wristwatch" cristal but the power consumption, stability and acuracy would not be optimised. * My target is the Actel A3P250 in TQFP100 package. I "could" use his Fusion sibling (that has an integrated and separately powered RTC oscillator) but the price difference is ... not enchanting. And the package is different. And I have the A3P250 already :-/ * I "could" use a common external I2C clock/calendar but i'd prefer SPI and the cheap chips don't (rarely ?) provide the 32KHz output (that I reuse to sequence stuff). So... what's left ? yg -- http://ygdes.com / http://yasep.orgArticle: 144297
On Nov 26, 1:10=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Wed, 25 Nov 2009 03:30:36 -0800 (PST), Claytong_nz wrote: > >These FPGAs are apparently okay in low earth orbit. My understanding > >is that they are already up there and working fine - at least the > >older technologies such as this part > > yeah, I guess they are fairly bulletproof (antifuse, 0.18um, ...) > > >now hand-tied by ITAR - hence the US guys are not permitted to help > > sheesh! > > >I'd like to take you up on your programmer offer > > I'd be happy to see it go to a good home; I don't see myself ever > using it again. =A0You get three or four 12x16B 84PLCC thrown in :-) > And I'll try to find my archived copy of the software, but > no promises on that; I haven't used it for years. > > > (or possibly purchasing it) > > Nah, you can have it - but we need to find a shipment method > that doesn't cost me anything, and doesn't cost you very much. > > >BTW, where are you? > > Oxford, England - but working in Munich, Germany for much of > the next few weeks. > -- > Jonathan Bromley, Verification Engineer > > Verilab =A0www.THAT_COMPANY.com Thank you. Your offer is very much appreciated Jonathan. I'll see if we can find someone local to you to collect or some other arrangement. ClaytonArticle: 144298
Sorted it...
I found this article a few hours ago:
<http://www.fpga-site.com/kiss.html>
... and just got around to reading it. That got me thinking... maybe it's
the data-separator that's upsetting the timing analyser, not the clock
divider.
So I started looking for gated clocks in the separator -- turns out the
Data Window flip-flop is wired to toggle (i.e. divide its clock by two;
not-Q wired to D), and is clocked from the most significant bit of the
DPLL shift register...
module DataSeparator(MASTER_CLK, FD_RDDATA_IN, SHAPED_DATA, DWIN);
input
MASTER_CLK; // Master Clock -- Data rate * 16
input FD_RDDATA_IN; // L->H
on flux transition
output SHAPED_DATA; //
Reshaped data pulses
output
DWIN; // Data Window
/////////////////////////////////////////////////////////////////////////////
// "Phase-jerked loop" data separator
// Designed by James Thompson, Analog Innovations, Phoenix AZ.
// Verilog implementation by Phil Pemberton
// Declare flipflops
reg u2a, u2b;
// U2A -- first synchroniser.
wire u2a_nPreset = u2b;
always @(posedge FD_RDDATA_IN or negedge u2a_nPreset) begin
if (!u2a_nPreset) begin
u2a <= 1'b1;
end else begin
u2a <= 1'b0;
end
end
// U2B -- second synchroniser
wire u2b_clk = !MASTER_CLK;
always @(posedge u2b_clk) begin
u2b <= u2a;
end
// U4A -- provides SHAPED_DATA
reg SHAPED_DATA;
always @(posedge u2b_clk or negedge u2b) begin
if (!u2b) begin // clear
SHAPED_DATA <= 1'b0;
end else begin
SHAPED_DATA <= u2b; // clock; D=u2b's
output
end
end
// PJL shift register
reg [7:0] pjl_shifter;
always @(posedge MASTER_CLK or negedge u2b) begin
if (!u2b) begin
// Asynchronous CLEAR
pjl_shifter <= 8'b0000_0000;
end else begin
// Clock
pjl_shifter <= {pjl_shifter[6:0], !pjl_shifter
[7]};
end
end
// PJL output register
reg DWIN;
always @(posedge pjl_shifter[7]) begin
DWIN <= ~DWIN;
end
endmodule
A closer look in the timing report showed the path... clk0 output of the
PLL to the MSB of the shifter. Hm.
I've rewritten the last block like this:
// Latch the state of the SR output
reg srout;
always @(posedge MASTER_CLK) begin
srout <= pjl_shifter[7];
end
// PJL output register
reg DWIN;
always @(posedge srout) begin
DWIN <= ~DWIN;
end
So now the output is clocked from the master clock, thus making most of
the data separator synchronous (the only exception I can see is the first
input synchronisation FF, U2A), and eliminating the timing issue.
But now I'm wondering if there's a better way to do this... I've got a
design for a state machine based data separator from a Western Digital
application note[1], but it suffers from a similar issue -- a DQ f/f
wired to toggle, clocked from the MSB output of the state machine PROM.
Making sense of the logic behind either the Analog Innovations "shift
register DPLL" isn't too hard once you start stepping it through, but the
WD one is an utter beast... And they very helpfully didn't bother
documenting it beyond saying "figure 12 shows a data separator built
around a state machine" and providing a ROM dump :-/
[1] "FD179x Application Notes". Western Digital, June 1980; p. 12,
"Figure 12: 179x Data Separator." <http://www.bitsavers.org/pdf/
westernDigital/FD179X_Application_Notes_Jun80.pdf>
Thanks,
--
Phil.
usenet09@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "09" with the last two digits of the current
year.
Article: 144299On Nov 26, 9:22=A0am, whygee <y...@yg.yg> wrote: > > So... what's left ? It's not clear exactly what you are asking ? Epson, EM Microelectronic et al, have 32Khz osc modules, that include the crystal. Maxim have one that is TCXO as well, and if precision matters, then you will need txco. NXP PCF2129 is another candidate, but less stocked. MicroCrystal.com also have a range. Some tcxo's are fixes in time, not frequency, so watch the details ;) -jg
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