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
Jim Granville wrote: > JustJohn wrote: > > As described, using 470K resistors, the power for that 3 pin RC > > oscillator looks miniscule. > > RC Osc power is not just resistor power; a significant amount is the > linear-region Icc from the pin buffers that are not square wave driven. > 1) (Jim) Do you have a more precise quantifier than "significant"? To be clear, I'll be referring to Peter's circuit (I can't post one myself, and am too lazy right now to attempt ASCII artwork). Let's call the top resistor Rc, since it charges the Cap, and call the bottom one Rs, since it feeds a Sense pin. This simple circuit brings a nice collection of subtleties with it:.. There are roughly three regions of operation (six, it's a symmetric circuit, let's look at just after switching C to ground): A) Immediately after switching , C has pushed Rs to VCC/2 below ground, and C is charging through both Rc (via the inverted output pin) and and Rs (via the sense pin protection diode). B) Some time later, the sense pin protection diode is no longer fwd biased, and C is charging through Rc only. Rs serves only to connect C to the sense pin (I'll assume that frequency is low enough that sense pin capacitance can be ignored). C) Sense pin reaches linear region, starts causing Icc current draw, in addition to the charging current Rc. I hadn't thought much about FPGA input structure before this. I had generally assumed, unlike logic buffers such as 'ALVC245 and the like, whose totem-pole inputs can consume enough power near threshold to destroy themselves, that newer multistandard FPGA inputs were more like a comparator, and not subject to damage, or even very much increase in current when near threshold. There are no warnings in the datasheet...certainly no "Icc current vs. input voltage" chart to indicate that near threshold operation is of concern.. 2) Can anyone say anything about Icc vs. input level for either FPGAs or, eg. CoolRunnrer PLDs? > > Add a little more gating, you can even shut it off, and re-start time > > doesn't look much more than half a clock period. > > Restart time is instant, but you do need to watch the start(idle) values > as the first half cycle time can differ from the others, as the circuit > changes from rest state, to the ping-pong oscillation cycles. Of course charging starts immediately, I meant the time from enable to the 1st threshold crossing at the sense pin. I was wrong in saying "more" than half a clock period. The first half period should be shorter than periods that follow, because C only has to charge from ground to threshold, while in later half periods, C charges from ~VCC/2 below ground to threshold. > With 3 terminal Osc's, you should also design the Pinout/PCB, so the > 'linear' node is adajcent to the positive acting pin(cap), and not the > negative acting pin. eg a good pinout is : GND RC Cap+ Res- >Article: 106476
On Mon, 14 Aug 2006 10:24:02 +1000, Mark McDougall <markm@vl.com.au> wrote: >I used to swear at Quartus, but now I have a new-found appreciation for >it! And whoever decided that the ISE files should be binary... just give >me *two* minutes alone with them... >:/ But please, let me watch it :-) GerhardArticle: 106477
Hello,
I'm still working on my diploma thesis with uC/OS and the Micrium TCP/IP Stack. I'm working with the Ml403 Xilinx Board and with the Microblaze. I use the Xilinx EDK and the RTOS is working fine and the Stack too. I posted my problem in several forums. It's not really a problem with the RTOS or the Stack.
I want to show you the last mail I send to Xilinx:
It takes still 17 us to post the semaphore. Now I have got some questions:
I load all variables in the BRAM: .rodata,.sdata,.data
First I did an arithmetic operation in my ISR (only a test):
PCM_mWriteDEBUG(PCM0_BASEADDR, 0x01); (Chipscope)
ccx= 50+bb*100/20+cc; (alles globale Variablen)
PCM_mWriteDEBUG(PCM0_BASEADDR, 0x00);
My first question: When I set the optimization level to one or above, the operation will be deleted. Why?
Link to the pictures: <http://img152.imageshack.us/img152/144/12345rj8.jpg> <http://img152.imageshack.us/img152/144/12345rj8.jpg>
Here is a picture when I trigger the first time the ISR is entered: (1)
It takes around 8 cycles for the first 4 Instructions, that seems correct.
Here is a picture when I trigger again: (2)
For the same Instructions it takes now ca. 10 times longer, the access to the BRAM too.
And now the same thing with the semaphore:
The first run takes ca. 1us and later ca. 17 us.
PCM_mWriteDEBUG(PCM0_BASEADDR, 0x01);
os_err = OSSemPost(PCM_Signal);
PCM_mWriteDEBUG(PCM0_BASEADDR, 0x00);
(3)
28002cdc: b0002803 imm 10243 28002ce0: e8a0f564 lwi r5, r0, -2716 // 2803f564 <PCM_Signal> 28002ce4: b0000003 imm 3 28002ce8: b9f4c494 brlid r15, -15212 // 2803f17c <OSSemPost> 28002cec: 80000000 or r0, r0, r0
(4)
2803f1d0: f873001c swi r3, r19, 28 2803f1d4: e873003c lwi r3, r19, 60 2803f1d8: e063000a lbui r3, r3, 10 2803f1dc: bc030044 beqi r3, 68 2803f1e0: e8b3003c lwi r5, r19, 60 2803f220: e873003c lwi r3, r19, 60
The timings when I trigger again:
(5)
I tried to load some Files to the BRAM and I did the following:
.text : { __text_start = .;
* (EXCLUDE_FILE(C:/DiplomEDK/Final/PCMLAN/microblaze_0/libsrc/uCOS-II_v2_81_a/src\ /os_sem.o).text)
* (.text)
* (.text.*)
* (.gnu.linkonce.t*)
__text_end = .; } > DDR_SDRAM_64Mx32_C_MEM0_BASEADDR
.bram_text : { __bram_text_start = .;
C:/DiplomEDK/Final/PCMLAN/microblaze_0/libsrc/uCOS-II_v2_81_a/src/os_sem.o(.text\ )
__bram_text_end = .; } > ilmb_cntlr_dlmb_cntlr
The file will not be found without the path.
The functions are still located in the DDR-RAM.
I can't write down everything I tried in the last weeks but I tried several solutions and nothing works. May be somebody had the same problem and can help me.
In my opinion it is not a problem with the RTOS or the stack. When the Microblaze need over 20 cycles for a simple add instruction it's more a problem with the EDK,Hardware... . Am I right? My tasks run correct and I can send and receive data over LAN.
So I hope somebody can help me.
Cu Emp
Article: 106478JustJohn wrote: > Jim Granville wrote: > >>JustJohn wrote: >> >>>As described, using 470K resistors, the power for that 3 pin RC >>>oscillator looks miniscule. >> >>RC Osc power is not just resistor power; a significant amount is the >>linear-region Icc from the pin buffers that are not square wave driven. >> > > 1) (Jim) Do you have a more precise quantifier than "significant"? For a good example graph, look at the data of the 74LVC14A, Fig 9 on my copy. http://www.standardics.philips.com/products/lvc/pdf/74lvc14a.pdf Here, you'll see the classic double peaks of a Schmitt transfer. Non-Schmitts are worse: Similar skirts, but with a single, higher peak. There can be variations in the peaks, and skirt shapes. A two terminal Osc will trace the 'butterfly' between the peaks, and so average 4mA Icc on this device. A three terminal osc is appx 25-30% of that. > To be clear, I'll be referring to Peter's circuit (I can't post one > myself, and am too lazy right now to attempt ASCII artwork). Let's call > the top resistor Rc, since it charges the Cap, and call the bottom one > Rs, since it feeds a Sense pin. This simple circuit brings a nice > collection of subtleties with it:.. > > There are roughly three regions of operation (six, it's a symmetric > circuit, let's look at just after switching C to ground): > A) Immediately after switching , C has pushed Rs to VCC/2 below ground, > and C is charging through both Rc (via the inverted output pin) and and > Rs (via the sense pin protection diode). > B) Some time later, the sense pin protection diode is no longer fwd > biased, and C is charging through Rc only. Rs serves only to connect C > to the sense pin (I'll assume that frequency is low enough that sense > pin capacitance can be ignored). > C) Sense pin reaches linear region, starts causing Icc current draw, in > addition to the charging current Rc. > > I hadn't thought much about FPGA input structure before this. I had > generally assumed, unlike logic buffers such as 'ALVC245 and the like, > whose totem-pole inputs can consume enough power near threshold to > destroy themselves, that newer multistandard FPGA inputs were more like > a comparator, and not subject to damage, or even very much increase in > current when near threshold. There are no warnings in the > datasheet...certainly no "Icc current vs. input voltage" chart to > indicate that near threshold operation is of concern.. I'm not sure about damage, but certainly the 4mA linear region of the LVC14a example, might play havoc with someones uA power budget. Modern FPGAs are pretty poor low power devices, so you'll likely just get a shrug from their vendors, but some CPLDs are sub 20uA, and so this can be important. It _should_ be in the uA CPLD data sheets. I have to smile at the MAX II low power marketing spin, where they REMOVE the power, to claim 'low power', and add many discrete components to do this. Remember Resistor-Transistor Logic ? > > 2) Can anyone say anything about Icc vs. input level for either FPGAs > or, eg. CoolRunnrer PLDs? It is not hard to measure this, especially once you understand the basic shape, and the peak(s) you are looking for. You do need to have a low voltage drop across the current sense. -jgArticle: 106479
David M. Palmer wrote: > The Wishbone appnote > http://www.opencores.org/projects.cgi/web/wishbone/appnote_01.pdf > says the following are the signals. I have marked them with Y or N > depending on whether your entity rs232_sender (for definiteness) has > them: > 1) Common signals: > Y CLK_I > Y RST_I > N TAG_I/O > 2) Data signals > Y DAT_I/O > 3) Bus Cycle signals > Y ACK_I/O > N ADR_I/O > N CYC_I/O > N ERR_I/O > N SEL_I/O > N RTY_I/O > Y STB_I/O > N WE_I/O I don't think that you need all signals, e.g. the example on page 108 in the specification at http://www.opencores.org/projects.cgi/web/wishbone/wbspec_b3.pdf uses only ACK_O, CLK_I, DAT_I, DAT_O, RST_I, STB_I and WE_I. Ok, after reading it again, the required signals are: For MASTER: ACK_I, CLK_I, CYC_O, RST_I, and STB_O For SLAVE: ACK_O, CLK_I, CYC_I, STB_I, and RST_I For SYSCON I'm not sure, but looks like CLK_O and reset RST_O. So I have to add the CYC signals to my cores. > For example, if you have many different > registers in a core that you are addressing with the ADR lines, are you > supposed ot decode all 32 address lines, or should there be a bus > controller that recognizes the high-order address bits and controls STB > and WE accordingly? I don't know if it is required, but a bus controller would be a good idea anyway, because otherwise the address decoding logic has to be duplicated in every device and it makes it more difficult to change the address mapping, e.g. if you use a "generic" parameter in VHDL for specifying a 2 bit number for the highest order bits for selecting the device and the you need 5 devices, you have to change your core instead of just the memory controller. > Is that generated by Wishbone Builder? No, I didn't know that such a tool exists and it was good for learning to do it manually, but for the next version I'll try the builder :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106480
KJ wrote: > > > > The issue is every time I do the place and route the Post place and > > route simulation results are different. One of the two state machines > > hangup. I'm not getting the possible reason for this. > > > > > - Clock(s) are running faster in simulation than the place and route > report says is acceptable (i.e. sim runs at 50 MHz, but the timing > report says that the best it can do is 10 MHz) > > - Setup times on input pins are being violated. Again the timing > report out of place and route will tell you what the setup time for > each pin is relative to whatever clock signal it is referenced to. If > your simulation model does not adhere to this (i.e. maybe inputs are > changing just prior to the rising edge of the clock) than you won't > simulate correctly. I'm implementing a manchester decoder. There are two asynchronous inputs. To decode the data, we sample this data using a local clock(16MHz, synthesys report mentions maximum clock around 40MHz). Therefore setup time may or may not be met. I suppose in actual hardware, if setup/hold time requirements are not met, the FF would remain in same state, and it will change state in next clock cycle when timing requirements are met. Please correct me if I'm wrong. Thanks and Regards, Srikanth > > Bottom line is to do timing analysis first and then make sure that the > simulation model that surrounds the design does not violate those > timing constraints. > > KJArticle: 106481
I've implemented a CRC32 core with 4 bit update (because the ethernet controller sends 4 bits at a time and a CRC32 core with 4 bit update is smaller than with 8 bit update). I think I'll integrate it in my ethernet core without an interface, but if I would define an extra core with Wishbone interface for it, how would I declare the 4 bit input? The Wishbone specification says: | The WISHBONE DATASHEET MUST indicate the port size. The port size | MUST be indicated as: 8-bit, 16-bit, 32-bit or 64-bit. Does this mean I can't use dat_i for the update data? With Verilog and VHDL it is no problem to use 4 bit port sizes or even odd sizes, like 3 bits. Is there any other drawback if I use 4 bit dat_i, besides from not conforming to the Wishbone spec? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106482
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message
news:44dfb517$0$12384$3b214f66@tunews.univie.ac.at...
> can't resist to answer ;-)
>
>>>
>> OK, lost again I think. Now it sounds like the CPU even though embedded
>> within the FPGA doesn't have a native Avalon interface and you're talking
>> about a bridge to get you from the CPU interface over to Avalon. Such a
>> bridge though would typically not be terribly application specific but
>> instead is tailored to the signals on the CPU and Avalon. Just like you
>> can make a bridge between Wishbone and Avalon. If the CPU design is your
>> homebrew though a simpler approach is to simply make it have an Avalon
>> compatible interface. When you get to writing that code is where my
>> template would be placed.
>
> It is a general case - not about my homebrew CPU:
>
> You have a component that (deeply inside not knowing it is connected
> to Avalon) triggers a read request. With your template this trigger
> gets registered when waitrequest is '0'. And this registering of
> the read request adds one cycle latency.
>
> Another point: If the waitrequest condition gets deeply embedded
> in the component it would
>
OK, for the homebrew (or anything where you own the 'master' side code) if
you want to bring out read/write and address combinatorially, the template
would then be
process(Put your signals here in place of clock)
begin
-- Not wanted for combinatorial version if rising_edge(Clock) then
if (Reset = '1') then
Read <= '0';
Write <= '0';
-- Address, Writedata, Next_State initializations go here also
-- Note: For the synchronous version of the template, address
-- and Writedata inits are not required since there is no Avalon
-- requirement for such. For the combinatorial version they
-- are needed either here or (more safely) outside the entire
-- if statement to provide a default to avoid latches.
elsif (WaitRequest = '0') then
-- Put your code here for whenever it is you want to read/write
-- When writing you would also set WriteData here
-- Also set Address of course
-- Next state of state machines (if any) would be put here also
else
-- Read, Write, Address and Writedata get set to hold their
-- current state. The registers for this would be in the
-- 'second' process of the two process approach.
-- If any state machines are in here than they would also have
-- the equivalent of 'Next_State <= Current_State here.
end if;
-- end if; Not wanted since this is no longer combinatorial
end process;
Besides the obligatory differences in the sensitivity list and 'if
rising_edge' all I've added is the 'else' branch to hold the current state
at whatever it happens to be at. This same code could also have been added
to the synchronous template version but would not be necessary. With the
combinatorial version it would be required of course to avoid latches.
Again using either template one can
- Be assured of meeting Avalon compatibility since it will be painfully
obvious that the Avalon signals will not change state on a clock cycle when
wait request has been set.
- The guts of the state machine (i.e. the section between 'elsif
(WaitRequest = '0') then' and the 'else' will not be littered with checks
about wait request with the potential that one check will be forgotten
leading to a possible Avalon incompatibility that may be difficult to debug
down to.
- The code for the guts of the state machine can concentrate on doing what
it needs to be doing which is reading/writing the Avalon bus upon requests
from the CPU side.
Again, these templates would be for master side code where the native
interface is Avalon.
> BTW: for my CPU design - as Avalon is Altera specific I would
> never make Avalon the native interface. JOP runns quite well on
> Xilinx devices ;-)
That being the case then the Altera specific code is performing the function
of a bridge between the CPU bus and the Avalon bus and would be segregated
as such. The ease/difficulty of that bridge design would then be a function
of how close/different those two busses are.
In any case, you certainly know your design far better than I and obviously
have been able to master Avalon enough to put together a working JOP design.
KJ
Article: 106483"Srikanth BJ" <bj.srikanth@gmail.com> wrote in message news:1155549204.939690.165840@75g2000cwc.googlegroups.com... > > I'm implementing a manchester decoder. There are two asynchronous > inputs. To decode the data, we sample this data using a local > clock(16MHz, synthesys report mentions maximum clock around 40MHz). > Therefore setup time may or may not be met. I suppose in actual > hardware, if setup/hold time requirements are not met, the FF would > remain in same state, and it will change state in next clock cycle when > timing requirements are met. Please correct me if I'm wrong. > If setup times are not met then you don't know if the FF will change, stay the same or even go metastable for a bit. The general approach to synchronizing async input to a clock is to bring the async signals into a FF then feed that FF output into a second FF. The output of the second FF is the only thing that then gets used further on down in the design. Since you have two async inputs, if one of them is some form of clock that the other signal is referenced to then you would need to bring them in, do the required clocking between the two and then transfer the remaining signal into your local clock domain. But, since you're still in the 'simulation' world though you don't have metastability as an issue. But the post route simulation model does model the required setup delays and clock to output delays so if you 'violate' timing by having inputs change at the wrong time relative to the local clock then the post-route simulation model will just sit there for an extra local clock cycle which would end up making the pre and post-route simulations be off by a clock cycle. There is no 'solution' to this problem though. Since the inputs to the design are asynchronous to the local clock any supposedly equivalent simulation model that attempts to model actual delays (i.e. the post-route model or the actual device itself on a board) will differ from a model that does not attempt to model those delays (i.e. the original design source). That's a big reason why post-route simulations are not quite as useful as one would hope for. One possible kludge would be to artificially synchronize those async inputs to your local clock before bringing them into your design. This assumes that the local clock is visible outside the design you're testing. If you do that, then you should be able to get a perfect match between pre and post-route simulation. Like I said though it's a kludge. Complete functional simulation and static timing analysis are the tools of the trade, post-route sim is an attempt to give the warm fuzzies because of inadequate or incorrect static timing analysis or incomplete testbench coverage. KJArticle: 106484
"John_H" <johnhandwork@mail.com> wrote in message
news:qqyDg.11048$hH1.10036@trnddc08...
>
> I appreciate the "fun" in delving deeper into this subject than I normally
> would go. If you want something "like" Manchester but with better
> behavior, perhaps CMI is an encoding to consider.
>
I think CMI has a problem with four times oversampling. From G.703:-
<quote>
CMI is a 2-level non-return-to-zero code in which binary 0 is coded so that
both amplitude levels, A1
and A2, are attained consecutively, each for half a unit time interval
(T/2).
Binary 1 is coded by either of the amplitude levels A1 or A2, for one full
unit time interval (T), in
such a way that the level alternates for successive binary 1s.
For binary 0, there is always a positive transition at the midpoint of the
binary unit time interval.
For binary 1:
a) there is a positive transition at the start of the binary unit time
interval if in the preceeding time interval the level was A1;
b) there is a negative transition at the start of the binary unit time
interval if the last binary 1 was encoded by level A2.
</quote>
So, a falling edge is the start of a symbol, no problem. The difficulty
comes when there's a binary one symbol coded as (b) above, followed by a
symbol of either type where the sampling point coincides with the rising
edge, followed by a long string of binary zeroes. Until the next binary one
comes along, it's not possible to resolve what the mystery bit is. I think
if you wait for the next binary one you can resolve the mystery bit, but
you'd need a fifo of depth equal to the longest string of zeroes you can
receive.
With four times oversampling.
| 0 | 1 | X | 0 | 0 | 0 | 0 | 0 |
00110000011100110011001100110011
^^
Which one of the marked bits is wrong?
BTW, excellent thread guys. It interesting that NRZ and RZ are much easier
to recover with low sample rates. This is because with NRZ a transition
means the start of a symbol, and ONLY occurs at the start of a symbol. With
RZ, a rising edge means the start of a symbol, a falling edge the middle and
ONLY those places. Manchester coding, and CMI to a lesser extent, suffer
from the problem that certain transitions can be either at the start or in
the centre of a bit. If only they didn't have DC, NRZ and RZ would be better
choices! It's easy to see why AMI coding is so popular.
Cheers, Syms.
Article: 106485This IPIF really sucks. About 8 months ago I built OPB peripheral (in EDK 7.1) with a wizard with everything included (DMA, master...). After months of testing I found out that DMA transfer doesn't work as it should, master also sucks... In EDK 8.1 wizard is the same using the same version IPIF files (2.x). IPIF 3.x is unfortunaltelly slave only, which is of no use. It is about time that Xilinx produces new IPIF for distributed DMA service (included in the peripheral) and master capabilities. After all the trouble I've been through I had to do it by myself (since I needed fast DMA). Central DMA sucks also, because It has 16 word fifo and data must be transferred twice resulting in a very poor performance (but you can take its master state machine as an example for building one!). So I bult a OPB peripheral with DCR register interface (for PPC) with a built in DMA (from peripheral to DDR ram only) and it works very well. Now I am adopting it to MicroBlaze, but I am encountering severe dificulties, because I have two OPB busses in a same peripheral - master and slave (separated!!). I am not sure if MicroBlaze architecture support multi-master OPB. Cheers, Guru MM wrote: > Sorry, talking to myself here... It's more mess than one could expect... > There is a doc subfolder for each of the versions. Only some of them have > datasheets included though. However, all of the datasheets share the same > DS414 number, but the revision history in each of them don't match! > Moreover, starting from v3.01a the datasheet became shorter and it doesn't > mention neither DMA, nor master functionality anymore!!! Again, no clue > about this in the revision history of the document :( > > I would appreciate if someone from Xilinx could help me to make some sense > of this... > > Thanks, > /MikhailArticle: 106486
"Brian Davis" <brimdavis@aol.com> wrote in message news:1155472497.883314.66650@m79g2000cwm.googlegroups.com... > > I haven't tried that out yet, but I don't see any fundamental problems > with it ( other than wasting BW vs. other modulation schemes. ) > > Brian > Hi Brian, Neat. I guess a problem could be that the signal has some data dependent DC component. But 8B10B coding fixes that. Cheers, Syms.Article: 106487
> > | The WISHBONE DATASHEET MUST indicate the port size. The port size > | MUST be indicated as: 8-bit, 16-bit, 32-bit or 64-bit. > > Does this mean I can't use dat_i for the update data? No, it just means that dat_i must be 8 bits wide (in your case) on the entity. It doesn't say that you have to use all 8 bits inside the architecture. When you go to synthesize this to a part, the synthesis will spot that those other 4 bits are not being used and optomize them away. In order to document your component you would also have to document the actual data format anyway so for those unused four bits you could simply say dat_i(7:4) are 'Reserved for future use'. KJArticle: 106488
On Sun, 13 Aug 2006, Davy wrote: "I am [..] confused with 4 arbitration schemes: Fixed priority;" The one with the highest priority wins. Simple. " Round Robin: simple, look-ahead-1,look-ahead-16? Is there any book or reference talk about arbiter schemes?" Almost any introductory or comprehensive book dealing with concurrency (e.g. books on multithreading or on operating systems or maybe books on networking) will contain a mention of fixed priority and round-robin scheduling.Article: 106489
No Idea about that? Another example: Assuming two counters from 0 to 10000 are multiplied. The result will be only 27 bits long, where the vectors (at least 14 bits each) would lead to one bit more ?Article: 106490
... when working with UNIX, you may want to use a specified script, forcing the compiler to put everything required into the "work" directory as destination with one "click".Article: 106491
Jim Granville wrote: > What we need is a CPLD like the Freescale RS08, or the SiLabs > C8051F41x - that works from 1.8V to 5.5V, and draws 1uA static Icc :) > [ ATF1502BE draws 2.3uA, but needs two rails.... ] The Coolrunner XPLA3 parts are pretty good. Other than not having schmitt trigger inputs, what don't you like about them? > > How about some details on the RC oscillator? I have not seen a 3 pin > > oscillator before. > > One Pin : Bidirectional pin, Open Collector, Res Pullup, Swings between > Schmitt VthP and VthN - Tolerance is that of Hyst Band. > Duty cycle is narrow. Hard to gate, as CAP is never 0V. > Can VCO modulate. If I understand correctly, this circuit would generate a sawtooth on the cap with a very short low drive time on the output. > Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups, > Swings from GND to VthP, Nominally 50% duty cycle. Gates very well > Can VCO modulate. I don't get this one at all. I looked up the 4046 but all descriptions I could find treat the VCO as a black box. I am guessing that the two pins are driven with opposite polarity and the cap is grounded at one end or the other all the time. So it would be charged like the one pin approach and then discharged like the one pin approach. So this is a pair of the one pin drivers to give you 50/50 duty cycle? This seems simple. Any issues with startup? Does it need FFs anywhere to make it work without noise? I would think that the lack of schmitt trigger inputs would require a FF. > Two Pin B : One IP, one OP, Classic HC14 Osc, single Rfb, and Cap, > Swings VthP to VthN, Duty cycle is nominally 50%, Poor VCO modulation. This one I know. > Three Pin: One IP and 2 OPs. (See 4060, 4541 et al) Positive feedback to > a CAP, negative feedback via resistor, with optional overshoot resistor > from CAP to IP pin. Needs layout to have +ve FB next to RC IP pin. > Has nominal immunity to pin thresholds, and some PSRR, poor VCO modulation. > > Gives lowest Icc, as the signal spends least time in high current IP > regions. > > Simplest form, is a non-inverter, followed by inverter (order matters). > > > Can have latches added, to 'de-fur' and can be gated with a little care. > > See the other link in this thread > http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=pa_six_easy&iLanguageID=1&iCountryID=1 > > This is a 3 termal RC osc, with a SR latch. This one is clear. Thanks.Article: 106492
Is there anybody out having experiences with an evaluation board, containing an Altera FPGA like Cyclone or Stratix and doing Video processing with it? Can anybody recoomend a certain board with a good analog behaviour (high dynamic ADC) - possibly with a (hard) DSP? Thanks in advance.Article: 106493
Dear all, I am struggling to find the information I need from the Xilinx datasheet, perhaps someone could provide me with some pointers. I am working with a Virtex 4 FX100 in a FF1152 package. I have 20 MGTs to play with, arranged in 10 tiles numbered 101, 102, 103, 105, 106, 109, 110, 112, 113 and 114. These are further arranged into columns. There must be a simple method for determining which tiles are in which columns, but I haven't worked it out. Perhaps a related problem is that I have no idea where the odd numbering scheme comes from. Any help would be greatly appreciated. TIA, -- PeterArticle: 106494
Borry.Wang@gmail.com schrieb: > One chip of Virtex 4,SX35F668,is used in my PCB board,When the board is > first assembled,the FPGA could performance very well,but about a month > later,the FPGA could not work correctly even download with the same > bitstream file once worked OK. I check the operate current of the total > board,the current is about 0.5A lower than normal(5V input > voltage),After the review every detail parameters of each ICs on the > board,the static resistor of 2.5V is much higher than > before(approximate 800ohm now but approximate 10ohm before),the 2.5V > is only provided to FPGA`s Vccaux and two banks`s Vcco.because the > Vccaux is provided to DCM,so I write a Program to test the 8 DCMs in > Virtex 4 SX35,the test result is that:every time I turn on the power > and load the same bitstream file to FPGA through JTAG,the output of the > 8 DCMs is not the same!Sometimes,2 or 3 DCMs`s output is not > correct,and the DCM lock signal keep low,the worst condition is 5 of 8 > DCMs`s output is not correct, and the correct DCM and incorrect DCM is > not fixed during each time. > > could anyone give me some advice to solve the problem? we have JTAG based frequency meter - clock analyzer http://xilant.com/ see second screenshot, it shows the 4 DCMs of Virtex 4 FX12 running in factory test mode, eg self oscillating. You should be able to use this tool to check your DCMs, the software uses Xilinx cable IV (in cable III compatible mode) and runs under WinXP. If you are interested to check out the DCMs with our tool let me know, I will create the SX35 bitstream for the DCM factory test setup for you. AnttiArticle: 106495
homoalteraiensis wrote:
> Assuming two counters from 0 to 10000 are multiplied. The result will
> be only 27 bits long, where the vectors (at least 14 bits each) would
> lead to one bit more ?
I would write some hdl code and run a simulation
to answer questions like that.
-- Mike Treseler
Article: 106496
KJ wrote:
> One possible kludge would be to artificially synchronize those async inputs
> to your local clock before bringing them into your design. This assumes
> that the local clock is visible outside the design you're testing. If you
> do that, then you should be able to get a perfect match between pre and
> post-route simulation.
That is what I do.
I just assume the synchronizer will work because
it always has and because the proof is not covered by
digital tools anyway.
> post-route sim is an attempt to give the warm fuzzies because of inadequate
> or incorrect static timing analysis or incomplete testbench coverage.
A post-route sim is a final check-off item to
prove that synthesis and my design rules
have worked for at least one case.
I keep it out of the edit, sim, edit loop
because it is slow to run, adds
little to timing or functional coverage,
and rarely fails.
It is more efficient to work on coverage
at full speed. An interesting measurement
is to sim the clock frequency outside the
specified range to see if there are
any logical limits built into the design.
-- Mike Treseler
Article: 106497? A multiplier with two 14 bit ports (as 10,000 = 0x2710H or 14 bits), e.g. the resulting operation has two 14 bit inputs, but some simple math (as in multiply 10,000 by 10,000) shows that the result requires only 27 bits (0x5F5E100H) as the input range is restricted. So, the MSB of the multiplier would never be asserted (used), and if this was a multiplier that was being synthesized, perhaps the tools are very smart, and because of the restricted range of the input variables, the output is recognized as not needing all 28 bits, and the unused logic is not created to begin with? That is awfully smart for the tools, as how did they "know" that the 14 bit inputs did not go to 0x3FFFH? (Who told the tools?) Is there a "range" menu for the multiplier function generator? AustinArticle: 106498
"Guru" <ales.gorkic@email.si> wrote in message news:1155556708.258128.130990@p79g2000cwp.googlegroups.com... > This IPIF really sucks. Do you know if PLB IPIF is any better? Thanks, /MikhailArticle: 106499
Try looking at this from the POV of the output, rather than the inputs... If you only hook up the lower 27 bits of the output, then the synthesis tool will know that the upper bit is never used (not the same as "never is one"), and optimize it out, to the extent possible in the hardware. In VHDL, you could use constrained integer types, that would automatically stop the simulation with an attempted assignment that is out of the range of the target variable/signal. This can be used on non-power-of-two limits also. signal terma, termb : natural range 0 to 10000; signal product : natural range 0 to 10000 * 10000; Andy Austin Lesea wrote: > ? > > A multiplier with two 14 bit ports (as 10,000 = 0x2710H or 14 bits), > e.g. the resulting operation has two 14 bit inputs, but some simple math > (as in multiply 10,000 by 10,000) shows that the result requires only 27 > bits (0x5F5E100H) as the input range is restricted. > > So, the MSB of the multiplier would never be asserted (used), and if > this was a multiplier that was being synthesized, perhaps the tools are > very smart, and because of the restricted range of the input variables, > the output is recognized as not needing all 28 bits, and the unused > logic is not created to begin with? > > That is awfully smart for the tools, as how did they "know" that the 14 > bit inputs did not go to 0x3FFFH? (Who told the tools?) Is there a > "range" menu for the multiplier function generator? > > Austin
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