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
Slave CPU ('C51) is connected to FPGA with 3 pins:
SCLK, SCODE1 and SCODE0.
SCLK and SCODE1 are inputs to FPGA.
SCODE0 is bi-dir.
C51 can:
- send data to FPGA (SHIFTIN);
- recv data from FPGA (SHIFTOUT);
- make FPGA execute something (EXECUTE).
C51 first places code in SCODE1-0 then clocks with SCLK:
0x SHIFTIN
10 EXECUTE
11 SHIFTOUT
SCLK and SCODE1 are synchronized to CLK:
if rising_edge(CLK) then
SCLK3 <= SCLK2; SCLK2 <= SCLK1; SCLK1 <= SCLK;
SCODE1C <= SCODE1B; SCODE1B <= SCODE1A; SCODE1A <= SCODE1;
end if;
Since SCODE0 is bi-dir, I track changes of SCODE1:
if rising_edge(CLK) then
if SCODE1C/=SCODE1B then -- change?
SCODE <= SCODE1 & SCODE0; -- register SCODE1-0
end if;
end if;
SCODE0 <= SHIFTOUT(7) when SCODE="11" else 'Z';
FPGA acts on rising edge of (sampled) C51 clock:
-- rising slave CLK
RSCLK <= '1' when (SCLK3='0' and SCLK2='1') else '0';
> How are you synchronizing action, actioncode and actionbit?
C51 places '0' on SCODE1 and that makes SCODE0 input.
Then it sends data on SCODE0 to FPGA, with SCLK as clock:
if rising_edge(CLK) then
if RSCLK='1' and SCODE="0-" then SHIFTIN <= SCODE0 & SHIFTIN(12 downto 1); end if;
end if;
The data C51 has transmitted is now in SHIFTIN register:
Action, actioncode and actionbit are bitfields (aliases) of SHIFTIN.
Next, C51 puts "10" on SCODE1-0 (EXECUTE) and clocks with SCLK:
-- from my first post, changed a bit:
if rising_edge(CLK) then
if WR3/=WR2 or RESET='1' then READY <= '0'; -- master/reset
elsif RSCLK='1' and SCODE="10" and SHIFTIN(12)='0' then -- slave, execute action
if SHIFTIN(11 downto 10)="00" then READY <= '1';
elsif SHIFTIN(11 downto 10)="01" then READY <= SHIFTIN(9);
end if;
end if;
end if;
Article: 144376Brian Drummond wrote: > On Fri, 27 Nov 2009 10:01:03 -0800 (PST), Gabor <gabor@alacron.com> wrote: > >> On Nov 25, 5:33 pm, Andy Botterill <a...@plymouth2.demon.co.uk> wrote: >>> webpack crashed whilst synthesising my design. > .... >>> Any ideas/pointers. Thanks in advance Andy >> If you're running ISE version 10.1 you should have a restore >> script for the project <project_name>.restore > >> If you're lucky and the original restore file hasn't >> already been clobbered, you should get back all of >> your settings. > > Trouble is, running ISE to discover the broken project file, you are liable to > rewrite the .restore file... > > - Brian Apologies for the delay. My home project got sidelined by some holiday. Synthesis in all forms is working OK. I'll run it until my testbench agrees with what I want and then move to a new project name/directory. On my FC8 desktop I've not had this sort of fault. On my FC11 laptop I get spontaneous crashes without any particular reason. dmesg shows a segfault. I will keep a close eye on this. Thanks for your time Andy.Article: 144377
On Wed, 02 Dec 2009 17:33:55 +0100 whygee <yg@yg.yg> wrote: > Hi, > > After all the clock generation stories, now comes the time > of time counting. So I want to implement a high-frequency > (<=100MHz ?) counter/timer that gets incremented by an auxiliary > input, and the problem comes from the clock domain crossing : > the low-frequency "acquire" signal must latch the counter > in another register but problems are likely to occur there. > > I have figured a "latch enable" logic that is synchronised > with the incoming signal, plus a simple R/S toggle for handshaking > but I presume that there are far better solutions. > Can anybody hint me ? > > yg One of the best high-frequency counters I've done in an FPGA was a ripple counter. Unlike a synchronous counter, a ripple counter only has a single point of entry that you need to gate, and so is safe for any asynchronous input signal up to hundreds of MHz. I wrapped a synchronous state machine around it that: 1) clock enables the first flip-flop in the counter 2) waits 1 second 3) deasserts the clock enable 4) waits 10 us for the ripple counter to settle out 5) registers the now static outputs back into the clocked domain 6) goto 1 The only problem is that you don't know for certain how long it will take the ripple counter to settle out, but if you're willing to go way, way overboard on that dead time then everything works like a dream. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 144378
Hi ! Rob Gaddi wrote: > One of the best high-frequency counters I've done in an FPGA was a > ripple counter. Unlike a synchronous counter, a ripple counter only > has a single point of entry that you need to gate, and so is safe for > any asynchronous input signal up to hundreds of MHz. My analog input seems to accept up to 65MHz which is well within the reach of the spare A3P250 that I have around (at 65MHz I can do a 32-bit adder and I only need a 27-bit counter). The analog front-end will attenuate before the A3P misses a pulse. > I wrapped a synchronous state machine around it that: > 1) clock enables the first flip-flop in the counter > 2) waits 1 second > 3) deasserts the clock enable > 4) waits 10 us for the ripple counter to settle out > 5) registers the now static outputs back into the clocked domain > 6) goto 1 hmmmm nice idea ! However this is going to waste 1/2 of the synchro pulses that I can get. If I have a stable 1Hz signal from a cheap GPS, I'll have a measurement only every 2 seconds. But abandonning the requirement of a second buffered register is a simple and easy way to avoid any glitch, sure ! > The only problem is that you don't know for certain how long it will > take the ripple counter to settle out, Oh, I could know (at least the max time with static timing reports), and the display/treatment latency would be hiding it anyway. > but if you're willing to go way, > way overboard on that dead time then everything works like a dream. No doubt about this :-) Or if it's a 1Hz clock, assuming a perfect 50% duty cycle, I can average during 1/2s and gate the input clock with the 1Hz directly. But I would't bet much on this, with rise/fall time inequality... thanks for the idea, yg -- http://ygdes.com / http://yasep.orgArticle: 144379
whygee <yg@yg.yg> wrote: > Rob Gaddi wrote: >> One of the best high-frequency counters I've done in an FPGA was a >> ripple counter. Unlike a synchronous counter, a ripple counter only >> has a single point of entry that you need to gate, and so is safe for >> any asynchronous input signal up to hundreds of MHz. (snip) >> I wrapped a synchronous state machine around it that: >> 1) clock enables the first flip-flop in the counter >> 2) waits 1 second >> 3) deasserts the clock enable >> 4) waits 10 us for the ripple counter to settle out >> 5) registers the now static outputs back into the clocked domain >> 6) goto 1 > hmmmm nice idea ! > However this is going to waste 1/2 of the synchro pulses that I > can get. If I have a stable 1Hz signal from a cheap GPS, I'll have > a measurement only every 2 seconds. But abandonning the requirement > of a second buffered register is a simple and easy > way to avoid any glitch, sure ! (snip) Implement two of them, each runs on opposite cycles of the 1Hz input clock. If you wait 1/2 cycle of the 1Hz clock to settle, you should be pretty safe against technology changes, too. -- glenArticle: 144380
glen herrmannsfeldt wrote: > Implement two of them, each runs on opposite cycles of the 1Hz > input clock. If you wait 1/2 cycle of the 1Hz clock to settle, > you should be pretty safe against technology changes, too. that's what I thought when writing the last message... however I went to eBay and found a distributor for cheap and used OnCore receivers with a 1pps pin. The doc says : >> Pulse width is approximately 200 ms (=B1 1 ms), >> i.e. the falling edge occurs approximately 200 ms >> after the rising edge so i'm stuck. But anyway, a 1pps with 2s of delay between measurements is still acceptable for me, as it's not used often. > -- glen yg --=20 http://ygdes.com / http://yasep.orgArticle: 144381
On Wed, 02 Dec 2009 19:53:53 +0100 whygee <yg@yg.yg> wrote: > glen herrmannsfeldt wrote: > > Implement two of them, each runs on opposite cycles of the 1Hz > > input clock. If you wait 1/2 cycle of the 1Hz clock to settle, > > you should be pretty safe against technology changes, too. >=20 > that's what I thought when writing the last message... >=20 > however I went to eBay and found a distributor > for cheap and used OnCore receivers with a 1pps pin. > The doc says : >=20 > >> Pulse width is approximately 200 ms (=B1 1 ms), > >> i.e. the falling edge occurs approximately 200 ms > >> after the rising edge >=20 > so i'm stuck. >=20 > But anyway, a 1pps with 2s of delay between measurements > is still acceptable for me, as it's not used often. >=20 > > -- glen > yg Ahh. You don't need a frequency counter, you need a period counter. I'm assuming you're trying to use the 1 pps GPS pulse to determine what frequency your clock is actually running at. In that case, why not just synchronize and rising edge detect the 1 pps pulse? --=20 Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 144382
Rob Gaddi wrote: > Ahh. You don't need a frequency counter, you need a period counter. > I'm assuming you're trying to use the 1 pps GPS pulse to determine what > frequency your clock is actually running at. right. So I can adjust the tuning capacitor of the crystal. > In that case, why not > just synchronize and rising edge detect the 1 pps pulse? my idea was to synchronize the 1pps input (and detect the rising edge of the pulse) to the crystal. Said another way : the crystal clocks a free-running shift-register/delay line, then some logic detects when the first N bits of the shift register are 0 and the last a 1s. The output of the AND gate toggles the latch enable of the output frequency register, for the next cycle (only). It "should" work but only in theory. Before wasting time on the FPGA design suite and the proto-board, I want to make sure that it has no obcious flaw that I missed :-) yg -- http://ygdes.com / http://yasep.orgArticle: 144383
On Wed, 02 Dec 2009 22:08:17 +0100 whygee <yg@yg.yg> wrote: > Rob Gaddi wrote: > > Ahh. You don't need a frequency counter, you need a period counter. > > I'm assuming you're trying to use the 1 pps GPS pulse to determine > > what frequency your clock is actually running at. > right. > So I can adjust the tuning capacitor of the crystal. > > > In that case, why not > > just synchronize and rising edge detect the 1 pps pulse? > my idea was to synchronize the 1pps input (and detect the > rising edge of the pulse) to the crystal. Said another way : > the crystal clocks a free-running shift-register/delay line, > then some logic detects when the first N bits of the shift register > are 0 and the last a 1s. The output of the AND gate toggles > the latch enable of the output frequency register, > for the next cycle (only). > > It "should" work but only in theory. Before wasting time on the > FPGA design suite and the proto-board, I want to make sure that > it has no obcious flaw that I missed :-) > > yg Yes and no. Basically, you're trying to design a frequency-locked loop. That mostly works, except that you're going to have problems with your frequency walking around. If you measure 1s with a 60 MHz clock, you'll get 60,000,000. But you could be off by up to 16 ppb before you'll see enough perturbation to be consistantly getting results that are above or below this. That's a deadband where you've got no loop gain, and so you're likely to wind up bouncing back and forth around in it. The usual way to solve this problem is to make a phase-locked loop instead, which can give you a lot more resolution on signals that are ever so slightly out of phase. There are a few tricks for this in an FPGA; one of the cuter ones is described in Xilinx XAPP250, where they hard code an internal delay line and use that to try to center up the rising edges of the crystal clock and the external signal. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 144384
I just found out that even the FDRSE version doesn't work on the long run. That test prog works for about 10sec with FDRE, or 20min with FDRSE, than fails.Article: 144385
Rob Gaddi wrote: > On Wed, 02 Dec 2009 22:08:17 +0100 whygee <yg@yg.yg> wrote >> It "should" work but only in theory. Before wasting time on the >> FPGA design suite and the proto-board, I want to make sure that >> it has no obvious flaw that I missed :-) > > Yes and no. Basically, you're trying to design a frequency-locked loop. Yes and no :-) The 1PPS signal is only a (planned) laboratory device, used when adjusting the cristal's leg capacitors. So the "loop" is loosely "closed" by a human operator (me) in order to get an appropriate frequency. I still want something very compact, as power-efficient as possible, and as cheap as reasonable, so putting a GPS receiver (even a "stamp-sized" one) in every board is not reasonable ;-) > That mostly works, except that you're going to have problems with > your frequency walking around. there are good ways to prevent this, look at http://jmfriedt.free.fr/lm_msp430.pdf OK I know it's french, but you'll understand the pictures, the code and the PI (without D) regulation functions. Oh, and there seems to be a mistake in fig.4 with the varicap. But I did not intend to do something so complex... At first I just wanted to make sure that my oscillators would not be too much out of frequency :-) > The usual way to solve this problem is to make a phase-locked loop > instead, which can give you a lot more resolution on signals that are > ever so slightly out of phase. There are a few tricks for this in an > FPGA; one of the cuter ones is described in Xilinx XAPP250, where they > hard code an internal delay line and use that to try to center up the > rising edges of the crystal clock and the external signal. I'll have a look, who knows what else i'll learn ? :-) regards, yg -- http://ygdes.com / http://yasep.orgArticle: 144386
On Dec 2, 6:06=A0pm, "aleksa" <aleks...@gmail.com> wrote: > I just found out that even the FDRSE > version doesn't work on the long run. > > That test prog works for about > 10sec with FDRE, or > 20min with FDRSE, than fails. What Andy was alluding to is that you have a timing problem. Less likely causes (but not totally improbable) of intermittent operation are: - power supply issues - Flaky parts - Non rad-hard parts operating near rad ...etc... Your most likely candidate though is a timing problem, so assume you have one...if it helps, pretend some slug wrote the code and you're the hired gun coming in to save the day. Some of your comments are contradictory (only one clock, but there are multiple things being clocked, there are multiple clocks) and without seeing the design will be tough to diagnose out here so here are the things to check out. 1. Verify that the timing report for Fmax is greater than the actual clock frequency. 2. Verify that the setup time requirement listed in the timing report for each input is actually being met in the real system. 3. Have the timing analyzer analyze all clock domain crossings or look at the final implementation for clock domain crossings...if you've gotten to this step, then this is likely your problem so turn a very critical eye to everything. Some questions to ponder (can also be pondered by looking at the source code) - If multiple bits get moved from one domain to another (maybe the two bits of 'ACTIONCODE' as an example) what one *other* signal is there that tells you that it is OK to sample these signals and that they are guaranteed valid? ALL clock domain crossings must consist of a single 'command/valid' signal and then the data payload that is being transferred. Either that or it must go through a dual clock fifo. - Does every clock domain crossing meet that requirement? - Did you verify that the requirement is met by viewing the final implementation? Kevin JenningsArticle: 144387
On Dec 2, 6:06=A0pm, "aleksa" <aleks...@gmail.com> wrote: > I just found out that even the FDRSE > version doesn't work on the long run. > Forgot to add on my previous post, that another effective technique (in most cases it is the most effective technique) is to simply bactrack and see where it leads. In your case, in the OP you said... "I wrote a test prog that has failed after several seconds. READY was set to '1' when it should have stayed '0'." Forget the part about "it should have stayed '0'", focus on what actually *did* happen which is that READY did go to '1'. Now backtrack by looking at your code and see what does this imply? From your posted code, it means that one of the two conditions must have occurred around the rising edge of CLK. 1. ACTION=3D'1' and ACTIONCODE=3D"00" 2. ACTION=3D'1' and ACTIONCODE=3D"01" and ACTIONBIT =3D '1'. Even if you think you know that neither condition could have occurred, you must be wrong. One of those two conditions MUST have occurred because READY did get set to 1. Now you continue the backtracking by forming a hypothesis about what must have occurred to meet the conditions for each path. Keep doing this for each path until you spot a likely source of the problem. Then try to verify that this is the case and only then do you fix it. You can keep this backtracking as a mental exercise until you're ready to test the most likely hypothesis. Alternatively, you can try to verify a particular hypothesis before moving on to cut down on the number of paths you need to analyze. To do this though you would have to modify the design in some fashion. Even if it means bringing out additional signals to see what is going on, that is a modification that can make the problem 'go under'. When a problem disappears, but you don't know why, that is the worst of all worlds because you can end up thinking that you've somehow 'fixed' something when in fact you haven't...and deep in your heart you know that problem is still there. The important thing is to forget about what *should* be occurring and simply take the facts (READY =3D '1') and use the source code of the design to backtrack through what must have transpired in order to make this event occur. By making modifications (like the rewrite that you did) without understanding why the original failed, you're making changes but you can't answer the simple question of why the original didn't work. Kevin JenningsArticle: 144388
[snip /] > >By making modifications (like the rewrite that you did) without >understanding why the original failed, you're making changes but you >can't answer the simple question of why the original didn't work. > >Kevin Jennings > This is sometimes called the "stochastic design method", and is related to the proposed simian rewrite of the complete works of Shakespeare - the time-to-complete is utterly unpredictable... ;-) Cheers, Robert --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144389
Hi all, I'm developing an FPGA (V5SXT50) containing a microblaze core. I have a problem that I do not understand how to find a solution. If I set the Software Platform Setting to use a standalone OS, all seems to work fine. The test applications (memory test, peripherals test ...) do not give me any errors. If I set Software Platform Setting to use a Xilkernel OS, then the memory test passes but the interrupt test doesn't pass. Seems that the microblaze doesn't see the interrupt generated by the timer. This is confirmed also by another problem I had when executing my final application, because I see that the thread are not switched and the application remains in the idle_task. Into the software platform settings I have correctly assigned the interrupt and timer resource. I'm using Xilinx EDK 10.1 SP3. Can anyone help me ? Thanks, Edoardo.Article: 144390
Hi, When using a synchronous FIFO, it seems like one can read and write into the FIFO at the same time. Does this means that the underlying memory is a Dual-Port blockram? If so, what is the cost of using such a dual port memory in a Xilinx FPGA. My experience is with ASIC, where most dual-port memory are about twice as big as their single-port counterpart. If the application permits the use a single port memory with a bit of logic avoiding the collision, it's definitely the way to go. However, if the Xilinx block ram are dual port 'for free', it's much easier to use the direct sync. FIFO... My application uses very fast burst writes, and continuous slow read. I could definitely use a normal single-port ram and make sure the burst-writes do not collide with the read. I just wonder if it's worth doing... Thanks! Diego --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144391
On Thu, 03 Dec 2009 11:17:58 -0600 "dlopez" <d@designgame.ca> wrote: > Hi, > When using a synchronous FIFO, it seems like one can read and write > into the FIFO at the same time. > > Does this means that the underlying memory is a Dual-Port blockram? > > If so, what is the cost of using such a dual port memory in a Xilinx > FPGA. My experience is with ASIC, where most dual-port memory are > about twice as big as their single-port counterpart. If the > application permits the use a single port memory with a bit of logic > avoiding the collision, it's definitely the way to go. However, if > the Xilinx block ram are dual port 'for free', it's much easier to > use the direct sync. FIFO... > > My application uses very fast burst writes, and continuous slow read. > I could definitely use a normal single-port ram and make sure the > burst-writes do not collide with the read. I just wonder if it's worth > doing... > > Thanks! > Diego > > --------------------------------------- > This message was sent using the comp.arch.fpga web interface on > http://www.FPGARelated.com The underlying BRAM in a Xilinx FPGA is a true dual port inherantly. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 144392
On Thu, 03 Dec 2009 11:17:58 -0600 "dlopez" <d@designgame.ca> wrote: > Hi, > When using a synchronous FIFO, it seems like one can read and write > into the FIFO at the same time. > > Does this means that the underlying memory is a Dual-Port blockram? > > If so, what is the cost of using such a dual port memory in a Xilinx > FPGA. My experience is with ASIC, where most dual-port memory are > about twice as big as their single-port counterpart. If the > application permits the use a single port memory with a bit of logic > avoiding the collision, it's definitely the way to go. However, if > the Xilinx block ram are dual port 'for free', it's much easier to > use the direct sync. FIFO... > > My application uses very fast burst writes, and continuous slow read. > I could definitely use a normal single-port ram and make sure the > burst-writes do not collide with the read. I just wonder if it's worth > doing... > > Thanks! > Diego > The FIFO macros basically, it seems to me, wraps a BRAM macro, which is dual-port for free and gratis. The cost you refer to has already been paid by the poor engineers at Xilinx who designed the BRAM. So, go ahead and save yourself the design effort, it won't really make a difference anyway. //OscarArticle: 144393
On Dec 3, 9:17=A0am, "dlopez" <d...@designgame.ca> wrote: > Hi, > When using a synchronous FIFO, it seems like one can read and write into > the FIFO at the same time. > > Does this means that the underlying memory is a Dual-Port blockram? > All Xilinx (Spartan or Virtex) BlockRAMs are dual-ported "for free", and for a FIFO application you therefore always use one port to write, the other one to read. Each port has its own controls, including clock and clock enable and write enable. The two ports can use independent clocks, but in that case, the generation of FULL and Empty is more complex, since these signals are being activated in one clock domain, and deactivated in the opposite one. That's what makes the design of high-performance asynchronous FIFOs so challenging. Peter Alfke, FIFO designer since 1970.Article: 144394
Diego, The Xilinx FPGA device has made all the choices for you, so it really doesn't matter how much area the BRAM takes, the real question is: "is the device I have chosen adequate to solve my problem?" Making a device with a single port memory for a FIFO might be more efficient in an ASIC, but in a FPGA device, it is best to build the most capable possible structures, in order to address the largest possible market. "FPGA thinking" is completely different from "ASIC thinking" in terms of efficiency, costs, areas. Not better, not worse, just different. AustinArticle: 144395
You can also use the distributed RAM to create a memory rather than the block RAMs. These are more resource efficient if you dont need large memories or some of the features of the block RAM like true dual port. Jon --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144396
Thanks a lot for the reply! So basically, in a Xilinx FPGA, a RAM is always a dual-port RAM! That does simplify my life for this project, so it's very good to know! I don't know much about the economics of FPGA, but it doesn't seem to be such a great thing for larger devices with a lot of RAM. Seems like the area hit might be quite large, given that most 'normal' designs requiring large memory only need single-port (I might be wrong here) ..unless Xilinx figured out a way to design a dual-port memory with zero overhead, but I've never heard of this so far! Thanks! Diego --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144397
Hi, Just got a question what to do if future needs fill up a Spartan-3A DSP 3400 CS484. A very quick and unqualified look at Spartan-6 family show a package called CSG484 with same physical dimensions as the CS484. Hope to do as few changes on the PCB as possible. Since the supply voltage is not the same, a drop-in replacement will not be possible anyway, but I would like to keep the rewiring need low. Anybody done this or thought of this who would share some impressions? -- SvennArticle: 144398
Svenn, The supply voltages are the same ... but the pinouts are different. AustinArticle: 144399
On Dec 3, 2:23=A0pm, Svenn Are Bjerkem <svenn.bjer...@googlemail.com> wrote: > Hi, > Just got a question what to do if future needs fill up a Spartan-3A > DSP 3400 CS484. A very quick and unqualified look at Spartan-6 family > show a package called CSG484 with same physical dimensions as the > CS484. Hope to do as few changes on the PCB as possible. Since the > supply voltage is not the same, a drop-in replacement will not be > possible anyway, but I would like to keep the rewiring need low. > Anybody done this or thought of this who would share some impressions? Xilinx doesn't believe in footprint-compatible parts. -a
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