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
On Saturday, September 4, 2004 3:43:01 AM UTC+5:30, Mukesh Chugh wrote: > Hi, > > I am facing following issues when using Xpower to calculate the > dynamic power for my design: > > Tools being used: > Xilinx ISE 6.2, Xpower 6.2.03i > ModelSim XE II/ Starter 5.7g > > I am generating the .vcd file during post PAR simulation and then > using this file for xpower along with .ncd and .pcf files. I get a lot > of warnings like: > > WARNING:Power:763 - Only 41% of the design signals toggle. > > WARNING:Power:216 - VCDFile(564214): $dumpoff command encountered, all > simulation data after this will be ignored. > INFO:Power:555 - Estimate is reasonable based on analysis of the > design, user > WARNING:Power:91 - Can't change frequency of net clk to 166.67Mhz. > WARNING:Power:91 - Can't change frequency of net clk to 165.83Mhz. > WARNING:Power:91 - Can't change frequency of net clk_BUFGP/IBUFG to > 165.83Mhz. > WARNING:Power:91 - Can't change frequency of net clk_BUFGP to > 165.83Mhz. > WARNING:Power:91 - Can't change frequency of net GLOBAL_LOGIC0 to > 0.83Mhz. > WARNING:Power:91 - Can't change frequency of net ce_IBUF to 0.83Mhz. > WARNING:Power:91 - Can't change frequency of net clk to 165.83Mhz. > WARNING:Power:91 - Can't change frequency of net clk_BUFGP/IBUFG to > 165.83Mhz. > parsing completed in: 0 secs > WARNING:Power:91 - Can't change frequency of net ce_IBUF to 0.83Mhz. > WARNING:Power:91 - Can't change frequency of net gateway_in4_0_IBUF to > 0.83Mhz. > WARNING:Power:91 - Can't change frequency of net gateway_in4_1_IBUF to > 0.83Mhz. > ...... > WARNING:Power:91 - Can't change frequency of net gateway_in4_8_IBUF to > 0.83Mhz. > WARNING:Power:91 - Can't change frequency of net gateway_in8_IBUF to > 25.83Mhz. > WARNING:Power:91 - Can't change frequency of net gateway_in10_IBUF to > 26.67Mhz. > WARNING:Power:91 - Can't change frequency of net gateway_in9_IBUF to > 25.83Mhz. > WARNING:Power:91 - Can't change frequency of net gateway_in5_0_IBUF to > 1.67Mhz. > WARNING:Power:91 - Can't change frequency of net gateway_in5_1_IBUF to > 0.83Mhz. > ...... > . > WARNING:Power:91 - Can't change frequency of net gateway_in3_3_IBUF to > 26.67Mhz. > WARNING:Power:763 - Only 42% of the design signals toggle. > WARNING:Power:763 - Only 42% of the design signals toggle. > > the report summary is > Power summary: I(mA) P(mW) > ---------------------------------------------------------------- > Total estimated power consumption: 553 > --- > Vccint 1.50V: 146 220 > Vccaux 3.30V: 100 330 > Vcco33 3.30V: 1 3 > --- > Clocks: 0 0 > Inputs: 3 5 > Logic: 61 91 > Outputs: > Vcco33 0 0 > Signals: 17 26 > --- > Quiescent Vccint 1.50V: 65 98 > Quiescent Vccaux 3.30V: 100 330 > Quiescent Vcco33 3.30V: 1 3 > Startup Vccint 1.5V: 200 > Startup Vccaux 3.3V: 100 > Startup Vcco33 3.3V: 50 > --- > > My Questions: > - How come I get clock power zero? In another smaller testdesign of > counters, I do get some power although logic power in that case is > very less. > - The activity rate for clock nets is zero. How? > - I get the correct simulation but the power results seem incorrect. > - Whats the meaningof such warnings? > > -- > Mukesh Hi, I am getting the same error. The error is WARNING:Power:91 - Can't change frequency of net log/result_cmp_eq0002 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<10>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<11>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<12>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<13>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<14>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<15>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<16>7 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<1>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<2>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<3>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<4>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<5>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<6>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<7>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<8>11 to 1.00Mhz. WARNING:Power:91 - Can't change frequency of net log/result_mux0000<9>11 to 1.00Mhz. Running Vector-less Activity Propagation ...... Finished Running Vector-less Activity Propagation Finished Running Vector-less Activity Propagation 0 secs The target device is Spartan 3E and ISE 14.2 I am unable to debug the error. Please give your input.Article: 156276
Hi,
thank you all for your comments.
The whole purpose of the exercise is to write the code in a way that is
maintainable. That's fairly in-line with assigning 'z' in this case. I
guess that's what I was looking for, to avoid hand-coding large numbers of
explicit muxes.
As it turned out, one type of construct was missing completely from my
Verilog vocabulary. Here is a simple example:
http://www.cs.indiana.edu/hmg/le/project-home/xilinx/ise_5.2/help/usenglish/fpgadesign/html/multi_verilog.htm
What I didn't know is that a later assignment does not "erase" an earlier
one completely, but they combine. I wonder what logic applies if more than
one value is non-z? Should find me a copy of the standard, or simulate.
I simulated and synthesized a short example, below. Simulation looks OK,
and the LED on the board cycles through four brightness levels, as
expected.
Cheers
Markus
module impl(input CLK32M,
output reg LED);
reg [26:0] ct = 0;
reg e1, e2, e3, e4;
wire a1 = e1 ? 0 : 'hz;
wire a2 = e2 ? (ct[15:0] < 2048) : 'hz;
wire a3 = e3 ? (ct[15:0] < 8192) : 'hz;
wire a4 = e4 ? 1 : 'hz;
// multiple assignment with z
wire nextLED;
assign nextLED = a1;
assign nextLED = a2;
assign nextLED = a3;
assign nextLED = a4;
always @(posedge CLK32M) begin
ct <= ct + 1;
e1 = 0; e2 = 0; e3 = 0; e4 = 0;
case (ct[26:25])
2'b00: e1 = 1;
2'b01: e2 = 1;
2'b10: e3 = 1;
2'b11: e4 = 1;
endcase;
LED <= nextLED;
end
endmodule
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 156277Thanks. I'll look into the bitgen options one day. In the Planahead GUI, there aren't too many, have to read the manual one day. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156278
PS the blocking "temporary" assignments probably open up another can of worms when it comes to coding style and religion. Well, I guess they do the job here, usually I'd avoid them or comment carefully. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156279
Please share the Linux SPI application. my email selvance@gmail.com Thanks..Article: 156280
hi I have been working as a VHDL programmer in a research center here in South Korea for the last 4 years. I have been fully involved in designing the FPGA codes and integrating it with the systems being developed in our lab to make the system work. We use altera cyclone 3 in our research center. I want to join and work in your company. how should I proceed? will be grateful to know HaryArticle: 156281
On 2/4/2014 10:23 PM, hary wrote: > hi > I have been working as a VHDL programmer in a research center here in South Korea for the last 4 years. I have been fully involved in designing the FPGA codes and integrating it with the systems being developed in our lab to make the system work. We use altera cyclone 3 in our research center. > > I want to join and work in your company. > how should I proceed? will be grateful to know > > Hary > > Hi Hary, Please post your resume here. Also supply a photo of your ID card, Drivers License, Marriage certificate and name and addresses of all family members. Thank YouArticle: 156282
On Monday, February 3, 2014 12:24:41 PM UTC-6, Mark Curry wrote: > Agree with Rob here. We just explicity use Wired-Or in our designs for th= ings > like this. I don't really see much use in using tristates in RTL code, wh= en > assigning to zero (when something's not used/not needed) is just as easy = as > assigning to 'z'. And as Rob notes, you're stating explicity what the too= ls > are going synthesize.=20 Ok, I'll even it up at two apiece with a note of support for Glen's positio= n... The point of synthesizable code is to describe the behavior of the circuit,= not necessarily its structure or implementation. To that end, there are di= fferent situations where the behavior may be more clear when expressed as t= ri-stated bus logic than wired-and or wired-or, or explicit multiplexer log= ic.=20 For instance, if you are developing a highly configurable system (via gener= ics or parameters) managing a configurable number of inputs to a mux (wired= -and, wired-or, or otherwise) is more cumbersome than multiple drivers of a= single bus.=20 Also, some technologies may favor wired-and or wired-or for performance rea= sons, and hard-coding a wired-or mux may not yield optimal results for all = target technologies. Letting the synthesis tool handle translation of a tri= -state bus to the optimal mux topology is beneficial.=20 Finally, when "bidirectional" data needs to be exchanged, nothing beats the= simplicity (and behavioral understandability) of a bidirectional tri-state= bus, compared to the multitudes of explicit connections and multiplexers (= priorityless or not) required otherwise. Tri-state descriptions can also be used to implement record-type ports with= different "directions" on each element of the record. Such ports can be ea= sily and simply connected to record signals, thus making the higher-level c= onnectivity easier to recognize (without so many trees, the forest can be s= een). AndyArticle: 156283
roopa.patavardhan@gmail.com wrote: > On Saturday, September 4, 2004 3:43:01 AM UTC+5:30, Mukesh Chugh wrote: >> Hi, >> >> I am facing following issues when using Xpower to calculate the >> dynamic power for my design: >> >> Tools being used: >> Xilinx ISE 6.2, Xpower 6.2.03i >> ModelSim XE II/ Starter 5.7g Are you really using software that OLD? I tend to use older software, but recently moved up to version 14. I'm surprised that software even supports Spartan 3E. JonArticle: 156284
On Wed, 05 Feb 2014 14:24:35 -0600, Jon Elson wrote: > roopa.patavardhan@gmail.com wrote: > >> On Saturday, September 4, 2004 3:43:01 AM UTC+5:30, Mukesh Chugh wrote: >>> Hi, >>> >>> I am facing following issues when using Xpower to calculate the >>> dynamic power for my design: >>> >>> Tools being used: >>> Xilinx ISE 6.2, Xpower 6.2.03i ModelSim XE II/ Starter 5.7g > Are you really using software that OLD? I tend to use older software, > but recently moved up to version 14. I'm surprised that software even > supports Spartan 3E. > > Jon No, roopa is using ISE14. The post he's replying to, however, is 10 years old... - BrianArticle: 156285
In article <FuyIu.16233$Ek5.1950@fx17.fr7>, Brian Drummond <brian3@shapes.demon.co.uk> wrote: >On Wed, 05 Feb 2014 14:24:35 -0600, Jon Elson wrote: > >> roopa.patavardhan@gmail.com wrote: >> >>> On Saturday, September 4, 2004 3:43:01 AM UTC+5:30, Mukesh Chugh wrote: >>>> Hi, >>>> >>>> I am facing following issues when using Xpower to calculate the >>>> dynamic power for my design: >>>> >>>> Tools being used: >>>> Xilinx ISE 6.2, Xpower 6.2.03i ModelSim XE II/ Starter 5.7g >> Are you really using software that OLD? I tend to use older software, >> but recently moved up to version 14. I'm surprised that software even >> supports Spartan 3E. >> >> Jon > >No, roopa is using ISE14. The post he's replying to, however, is 10 years >old... I've noticed a sudden uptick in these kinds of posts lately - i.e. replying to 5, 10 year old posts. Caught myself answering one on the Xilinx forums before I noticed how old the thread was... Think I even saw a 17 year old usenet thread replied to as well. Must be senior project time, one wonders? Just kinds of funny to see. --MarkArticle: 156286
Hi, I have just published a simple, parametrized synthesizable FFT engine, which allows the user to define the length of FFT (as power of two), define the format of the numbers and adjust the engine to the latency of the "butterfly block". I couldn't find similar open source solution, so I decided to publish mine. Of course it is the user's responsibility to implement the "butterfly block" working with the appropriate numbers representation. The sources are published under BSD license both on OpenCores ( http://opencores.org/project,versatile_fft ) and - the initial version on alt.sources ( subject: "Parametrized synthesizable FFT engine in VHDL", link to google archive: https://groups.google.com/forum/message/raw?msg=alt.sources/CTsFcaE8fD8/3lqMd_EiQ4MJ ) I hope, that this design may be useful for someone, even though it is optimized rather for moderate resources usage, then for performance. Sources provide the Octave script allowing to verify operation of the core. (Just run "octave test_fft.m" in Linux, with ghdl installed). -- Regards, WojtekArticle: 156287
On 2/5/2014 3:08 PM, Mark Curry wrote: > In article <FuyIu.16233$Ek5.1950@fx17.fr7>, > Brian Drummond <brian3@shapes.demon.co.uk> wrote: >> On Wed, 05 Feb 2014 14:24:35 -0600, Jon Elson wrote: >> >>> roopa.patavardhan@gmail.com wrote: >>> >>>> On Saturday, September 4, 2004 3:43:01 AM UTC+5:30, Mukesh Chugh wrote: >>>>> Hi, >>>>> >>>>> I am facing following issues when using Xpower to calculate the >>>>> dynamic power for my design: >>>>> >>>>> Tools being used: >>>>> Xilinx ISE 6.2, Xpower 6.2.03i ModelSim XE II/ Starter 5.7g >>> Are you really using software that OLD? I tend to use older software, >>> but recently moved up to version 14. I'm surprised that software even >>> supports Spartan 3E. >>> >>> Jon >> >> No, roopa is using ISE14. The post he's replying to, however, is 10 years >> old... > > I've noticed a sudden uptick in these kinds of posts lately - i.e. replying to > 5, 10 year old posts. Caught myself answering one on the Xilinx forums before > I noticed how old the thread was... > > Think I even saw a 17 year old usenet thread replied to as well. > > Must be senior project time, one wonders? > > Just kinds of funny to see. > > --Mark I was going to write something nasty about Google. But I erased it. Rob.Article: 156288
Hi, one RTL coding style for pipelined processing goes as follows: - set arguments to function with latency, i.e. memory lookup or multiplication - set a trigger bit (/multi-bit word) in a parallel shift register - when the trigger arrives at the output, continue processing - cascade multiple stages, i.e. first memory lookup, output triggers multiplication etc My question is: Is there any commonly accepted and proven way to code this in RTL? I see the above emerging as a "red thread" in my own code, maybe there is some "RTL design patterns" or 10-volume "The Art Of RTL Coding" that would discuss such ideas? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156289
In article <pvedndIrNdTRIW7PnZ2dnUVZ_sudnZ2d@giganews.com>, mnentwig <24789@embeddedrelated> wrote: >Hi, > >one RTL coding style for pipelined processing goes as follows: > >- set arguments to function with latency, i.e. memory lookup or >multiplication >- set a trigger bit (/multi-bit word) in a parallel shift register >- when the trigger arrives at the output, continue processing >- cascade multiple stages, i.e. first memory lookup, output triggers >multiplication etc > >My question is: Is there any commonly accepted and proven way to code this >in RTL? I see the above emerging as a "red thread" in my own code, maybe >there is some "RTL design patterns" or 10-volume "The Art Of RTL Coding" >that would discuss such ideas? I'm wondering how others handle this too. I've done lots of pipelined designs, but don't have a consistent design style with regard to these types of things. I've used spreadsheets (with "time") along one of the axis, and state along the other. Block diagrams, diagraming state values along side the registers, and other haphazard strategies. I don't usually code an explict handshake - after all the pipeline delays are fixed in the end. Calculating the "fixed" value can sometimes be tricky. But in the end you end with a fixed delay between "data in valid" and "data out valid". (This may vary, for instance with a parameter number of stages, but is still "fixed" in the end). You do have to be careful with matching latencies for stuff coming together, which is again tricky, but fixed. So often I lay down the "datapath" with the "din_valid" -> "dout_valid" delay just set along side in a SRL, with a tuneable depth. I often struggle with the "definition" of registers with respect to which register is just a "pipeline" register, and which are actual "Z-1" delays of the actual filter you're trying to design. There's some kind of trick here that I know I'm just missing. (I'm usually designing with a non-systolic clock - i.e. my processing clock has no relation to my sampling "clock"). So, not much advice here, just noting that I see the same issues.... Regards, MarkArticle: 156290
I'm having the same problem. The download manager is a big waste of my tim= e (half the day so far). I've tried Mac OS with Safari and Firebox, and Wi= n XP (in VirtualBox) with Internet Explorere. It all just fails to downloa= d. Just let me download MY way (either HTTP or FTP or RSYNC) !!!Article: 156291
Here http://www.xilinx.com/support/answers/57840.html is a link that lets you download the most recent ISE 14.7 (free webedition incl PlanAhead) without use of download manager. Which never worked for me. Before the link you had to edit the URL manually but I think that is now broken. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156292
Hi Mark, thanks for the comments. I did one design twice: Once with a hard-coded 15-state FSM, the other one with shift registers. The first one is more readable, the second one slightly smaller. But this may be because I usually end up with most registers unused, while LUTs are the bottleneck. Keeping multiple samples "in flight" for the hardware multiplier is so much work that I'm looking into bit-serial multipliers, maybe that's more rapid-prototyping-friendly for audio. Cheers Markus --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156293
Hello, I have designed an IP Core and I am using some registers to control it.Generally Microprocessor writes into these register and IP Core reads these registers.My question is which is the best way to provide synchronization between Microprocessor clock to IP clock if both clocks are different.Currently I am using 2-deep fifo to synchronize all my registers.But I feel it occupies more resources.So would someone please suggest me any other way? Thanks, Krupesh --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156294
kapatel <94438@embeddedrelated> wrote: > I have designed an IP Core and I am using some registers to control > it.Generally Microprocessor writes into these register and IP Core reads > these registers. When you say "reads these" what do you mean? > My question is which is the best way to provide synchronization > between Microprocessor clock to IP clock if both clocks are > different. Currently I am using 2-deep fifo to synchronize all my > registers.But I feel it occupies more resources.So would someone > please suggest me any other way? To answer the question, you have to decide what happens under various synchronization (or lack of) conditions? In many cases, the output of registers are control lines, so not, in the usual sense "read". In some cases, that means that bad or unusual things happen if the register bits change on different (on the IP core side) clock cycles. Just to be sure you aren't confused, not that the problem is not metastability (which is also a problem related to crossing clock domains). If you, for example, clock one register on one clock, and connect its outputs to a register clocked with a different clock, it is possible (and if you do it long enough, likely) that at some point the second register gets some bits from the one clock cycle, and some from the succeeding cycle. This is a form of race condition. Again, depending on the system that may, or may not, be bad. Now, consider how the FIFO works. The register contents gets clocked into the FIFO. If it is immediately available at the output (an option on some FIFOs) the same problem can occur as above. The fix, then, is that the data isn't available until the following clock cycle. Another feature of a FIFO is the subsequent input data won't change the value at the output. (It goes into a different FIFO cell.) But note that even that fails if you don't check the FULL flag. So, what you need is a register to write into, at least one clock cycle of the fastest clock delay before it is read out, and a guarantee that the first register doesn't change until the value is read out. That is somewhat simpler than a FIFO. (The latter guarantee can usually be arranged in the microprocessor logic.) -- glenArticle: 156295
kapatel <94438@embeddedrelated> wrote: > I have designed an IP Core and I am using some registers to control > it.Generally Microprocessor writes into these register and IP Core reads > these registers. > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >So, what you need is a register to write into, at least one clock >cycle of the fastest clock delay before it is read out, and a >guarantee that the first register doesn't change until the value >is read out. That is somewhat simpler than a FIFO. (The latter >guarantee can usually be arranged in the microprocessor logic.) Krupesh - you asked a very general question, so as Glen suggested, you need to be a bit more specfic. Glen's last paragraph generalizes things about as much as possible. I'll rephrase it - the hardware must be designed to only sample the register when it is known to be stable. There are often times in some of my logic design, where I have registers that I call 'Quasi-Static'. These registers are SW controllable, but they're set at initializaion, and never reconfigured. At the time they're set, the hardware is at a "don't care" state, since it's being initialized. For these type of registers, I don't do any synchronization at all. Just feed the register cross clock domains, and you're done. (I've got hooks in place to handle these timing exceptions inside the STA tools). There's other similar registers, for instance in video design, where registers are only updated during vertical blanking. I don't call these "quasi-static" but they are similar in nature for the hardware - they're static for when I care, only changing when they're not being used. They have 10s or 100s of clock cycles to stablize before being sampled. These don't get synchrononizers either. FIFO's IMHO are overkill for "Control" register type synchronization, normally. The exception is if that control register is changing often. My 2 cents... Regards, MarkArticle: 156296
I have a Mach02 demo board and am driving it with Lattice Diamond. With some searching I found io pin list of the device, but there are no power supply pins in that list. Probably something else is missing on that list too. There are many many data sheets and app notes from Lattice, but this is missing. Perhaps one good would have been better. The chip in the Mach02 board is Lcmx02-1200ze 1tg144, by the way.Article: 156297
LM wrote: > I have a Mach02 demo board and am driving it with Lattice Diamond. With some searching I found io pin list of the device, but there are no power supply pins in that list. Probably something else is missing on that list too. > > There are many many data sheets and app notes from Lattice, but this is missing. Perhaps one good would have been better. > > The chip in the Mach02 board is Lcmx02-1200ze 1tg144, by the way. The Device data sheet says: "For further information regarding logic signal connections for various packages please refer to the MachXO2 Device Pinout Files." But of course there's no link, and on their website under: Products --> MachXO2 --> documents --> datasheets the files are called "Package Migration Files" instead... See: http://www.latticesemi.com/~/media/Documents/DataSheets/MachXO23/MachXO2144-PinTQFPPackageMigrationFile.CSV -- GaborArticle: 156298
Den mandag den 10. februar 2014 20.46.15 UTC+1 skrev Mark Curry: > kapatel <94438@embeddedrelated> wrote: > > > > > I have designed an IP Core and I am using some registers to control > > > it.Generally Microprocessor writes into these register and IP Core reads > > > these registers. > > > > > > > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > > >So, what you need is a register to write into, at least one clock > > >cycle of the fastest clock delay before it is read out, and a > > >guarantee that the first register doesn't change until the value > > >is read out. That is somewhat simpler than a FIFO. (The latter > > >guarantee can usually be arranged in the microprocessor logic.) > > > > > > Krupesh - you asked a very general question, so as Glen suggested, you need > > to be a bit more specfic. > > > > Glen's last paragraph generalizes things about as much as possible. I'll > > rephrase it - the hardware must be designed to only sample the register when it > > is known to be stable. > > > > There are often times in some of my logic design, where I have registers > > that I call 'Quasi-Static'. These registers are SW controllable, > > but they're set at initializaion, and never reconfigured. At the time > > they're set, the hardware is at a "don't care" state, since it's being > > initialized. > > > > For these type of registers, I don't do any synchronization at all. Just feed > > the register cross clock domains, and you're done. (I've got hooks in place > > to handle these timing exceptions inside the STA tools). > > > > There's other similar registers, for instance in video design, where > > registers are only updated during vertical blanking. I don't call these > > "quasi-static" but they are similar in nature for the hardware - they're static > > for when I care, only changing when they're not being used. They have 10s > > or 100s of clock cycles to stablize before being sampled. These don't > > get synchrononizers either. > > > > FIFO's IMHO are overkill for "Control" register type synchronization, normally. > > The exception is if that control register is changing often. > > > > My 2 cents... > > > > Regards, > > > > Mark you could also just make a single synchronizer between the "busses", just like if you had a async memory interface i.e. register the addr/data/write on the processor side, transfer to the peripheral side and do synchronous write same for reads -LasseArticle: 156299
On Tuesday, February 11, 2014 10:33:02 PM UTC+2, Gabor wrote: > LM wrote: > > > I have a Mach02 demo board and am driving it with Lattice Diamond. With some searching I found io pin list of the device, but there are no power supply pins in that list. Probably something else is missing on that list too. > > > > > > There are many many data sheets and app notes from Lattice, but this is missing. Perhaps one good would have been better. > > > > > > The chip in the Mach02 board is Lcmx02-1200ze 1tg144, by the way. > > > > The Device data sheet says: > > > > "For further information regarding logic signal connections for various > > packages please refer to the MachXO2 Device Pinout Files." > > > > But of course there's no link, and on their website under: > > Products --> MachXO2 --> documents --> datasheets > > the files are called "Package Migration Files" instead... > > > > See: > > > > http://www.latticesemi.com/~/media/Documents/DataSheets/MachXO23/MachXO2144-PinTQFPPackageMigrationFile.CSV > > > > -- > > Gabor Thanks. That file seems to be usable. Too bad it is not possible to export the whole thing from project. It would make building pwb decals simpler.
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