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
>> The last days I played around with the Quartus SOPC builder [1]. >> Although I'm more a batch/make guy, I'm impressed by the easy to use >> tool. In order to scratch a little bit on the dominance of the NIOS II >> in the SOPC world I wrapped JOP [2] into an Avalon component ;-) > > Kudos, that is excellent. Any lessons/gotchas about turning JOP into an > SOPC components should someone else fancy a similar undertaking? The Avalon bus is very flexible. Therefore, writing a slave or master (SOPC component) is not that hard. The magic is in the Avalon switch fabric generated by the builder. However, an example would have helped (Altera listening?). I didn't find anything on Altera's website or with Google. Now a very simple slave can be found at [1]. One thing to take care: When you (like me) like to avoid VHDL files in the Quartus directory you can easily end up with three copies of your design files. Can get confusing which one to edit. When you edit your VHDL file in the component directory (the source for the SOPC builder) don't forget to rebuild your system. The build process copies it to your Quartus project directory. When you want to start over with a clean project the only files needed for the project are: .qpf, .qsf, .ptf The master is also ease: just address, read and write data, read/write and you have to react to waitrequest. See as example the SimpCon/Avalon bridge at [2]. The Avalon interconnect fabric handles all bus multiplexing, bus resizing, and control signal translation. >> However, of course there is some drawback. The performance of the >> Avalon system is lower than a 'native' connection (or in my case >> via SimpCon [5]) of the main memory to the CPU. I can provide some >> numbers if there is interest... > > Care to elaborate? I'd expect going over Avalon could add latency, but > if you can exploit multiple outstanding transactions (aka "posted > reads") and/or bust transfers, the bandwidth should be the same as > "native". Yes, the latency is the issue for JOP. JOP does not trigger several read or write transactions. However, it can trigger one transaction and than continue to execute microcode. When the (read) result is needed, the JOP pipeline is stopped till the result is available. What helps is to know in advance (one or two cycles) when the result will be available. That's the trick with the SimpCon interface. There is not a single ack or waitrequest signal, but a counter that will say how many cycles it will take to provide the result. In this case I can restart the pipeline earlier. Another point is, in my opinion, the wrong role who has to hold data for more than one cycle. This is true for several busses (e.g. also Wishbone). For these busses the master has to hold address and write data till the slave is ready. This is a result from the backplane bus thinking. In an SoC the slave can easily register those signals when needed longer and the master can continue. On the other hand, as JOP continues to execute and it is not so clear when the result is read, the slave should hold the data when available. That is easy to implement, but Wishbone and Avalon specify just a single cycle data valid. >> BTW: The Cyclone II FPGA cannot be clocked really faster than the >> Cyclone (just a few %). I hoped to get some speed-up for free due >> to a new generation FPGA :-( > > I was surprised too when I saw that. I gather the only way the Cyclone > II can gain you speed over Cyclone I is when you can use the embedded > multipliers. Makes me wonder about the upcoming Cyclone III. Are there any other data available on that. I did not find many comments in this group on experiences with Cyclone I and II. Looks like the CII was more optimized for cost than speed. Yes, waiting for III ;-) Martin [1] http://www.opencores.org/cvsweb.cgi/~checkout~/jop/sopc/components/avalon_test_slave/hdl/avalon_test_slave.vhd [2] http://www.opencores.org/cvsweb.cgi/~checkout~/jop/vhdl/scio/sc2avalon.vhdArticle: 106351
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag news:44ddb2d4$0$8024$3b214f66@tunews.univie.ac.at... >>> The last days I played around with the Quartus SOPC builder [1]. >>> Although I'm more a batch/make guy, I'm impressed by the easy to use >>> tool. In order to scratch a little bit on the dominance of the NIOS II >>> in the SOPC world I wrapped JOP [2] into an Avalon component ;-) >> >> Kudos, that is excellent. Any lessons/gotchas about turning JOP into an >> SOPC components should someone else fancy a similar undertaking? > > The Avalon bus is very flexible. Therefore, writing a slave or > master (SOPC component) is not that hard. The magic is in the Avalon > switch fabric generated by the builder. However, an example would > have helped (Altera listening?). I didn't find anything on Altera's > website or with Google. Now a very simple slave can be found at [1]. > > One thing to take care: When you (like me) like to avoid VHDL files > in the Quartus directory you can easily end up with three copies of > your design files. Can get confusing which one to edit. When you > edit your VHDL file in the component directory (the source for the > SOPC builder) don't forget to rebuild your system. The build process > copies it to your Quartus project directory. Hi Martin, most of the SOPC magin happens in the perl package "Europe" ASFAIK. dont expect a lot of information about the internals of the package. as very simple example for avalon master-slave type of peripherals there is on free avalon IP core for SD-card support the core can be found at some russian forum and later it was also added to the user ip section of the microtronix forums. the avalon master is really as simple as the slave. AnttiArticle: 106352
Jonathan Bromley wrote: > On 11 Aug 2006 14:16:19 -0700, rickman > <spamgoeshere4@yahoo.com> wrote: > > > >Thanks to everyone for their posts. Each of the above solutions > >require timing of the signal and so will not work without a clock (or > >timer) of a specified rate. > > I'm not sure I understand this. > > Give me an oscillogram of a Manchester-coded signal and I can > tell you its clock rate by inspection - unless the data stream > is all-1s or all-0s, and that's a corner case that we easily > know how to avoid. I need only one different bit in the > entire oscillogram and I can work out what's going on with > no _a priori_ knowledge of the data rate. Actually, that is not correct. Here are two sequences sampled at 1 MHz. Please tell me the clock rates. 0101010101010101 0011001100110011 But I acknowledged that you could "measure" the data rate as long as the bit stream allows for that. > To achieve this I need only two things: (a) some means to > measure the time between transitions, to a good enough > precision; (b) enough memory to remember what's going > on until I see a bit transition from 0 to 1 or back. Condition > (a) means, in digital-land, some kind of oversampling and > so it implies a *minimum* sampling clock rate; but > measurement of edge-to-edge times imposes no lower > limit on the data rate. > > I suspect rickman is looking for a scheme in which the > data line can provide its own clock using some method > other than oversampling. Pulse-position or pulse-width > modulation does that well enough, as do a whole raft > of PSK techniques, but all of them require some kind > of phase-locked loop or related means to act as a > "flywheel" so that you can detect deviations of the > line signal from an average clock that's also delivered > by the line. Pulse position and pulse with modulation still require a time measurement which requires me to have a time reference on the receiver. > Once you've introduced a PLL you are, of course, in > something like analogue territory; and once you're > there, a whole world of modulation techniques opens up. > Amplitude-shift keying sounds about as self-clocking > as it gets; there are ternary codes (positive-going pulse > for 1, negative-going to 0), ....... And in the absence of > any interfering signals these schemes are, trivially, > self-timed. Of course, as soon as you have other > signals present on the same line, the obvious way > to sort out one from another is by prior knowledge > of the clock frequency. Ask the radio guys about > that - they are probably likely to speak of a "carrier" > rather than "clock", and they may talk about "tuning" > to choose a given signal! If I am going to require a time reference at the receiver the simplest scheme I know of is just async serial data with a start and a stop bit. No point in using Manchester encoding if I am transferring the data over a wire just a few inches long.Article: 106353
Frank Buss wrote: > rickman wrote: > > > Thanks to everyone for their posts. Each of the above solutions > > require timing of the signal and so will not work without a clock (or > > timer) of a specified rate. > > With one pin you need a clock, or you can use 3 voltage levels: 0, 1/2 and > 1. Should be easy to generate with an op-amp and to detect with another > one. But I think it is easier to use a clock and normal digital signals. The problem is lack of pins. We are looking at a situation where we don't want to make a connector any larger. We need to multiplex two separate bidirectional serial data streams and four discrete signals over four or less pins. I was thinking about ways of doing this and realized that I had to provide a clock in the decoder. So I either have to use a pin or I have to add an oscillator to the decoder. Since the decoder will be in a cable, I need to keep it minimal. Actually, decoder is a misnomer since it will have to both send and receive. So I don't see any way to get around the need for a timing reference, either on a pin or by supplying an oscillator. Most likely it will be on a pin. Right now I like the idea of using I2C, but I will need to perform a detailed analysis of the tradeoffs vs. standard async with separate clock, I2C, SPI and Manchester encoding. I see there are some very small packages for CPLDs, but they don't have much logic in them. I don't know if I can design such a transceiver in 64 logic cells.Article: 106354
jai.dhar@gmail.com wrote: > Hey guys, > > I'm having trouble getting started with my first clock-domain crossing > task. I need to take in 2 signals; a 2.048M clock and associated data > stream, and transfer it to a 50M stream that outputs a single-pulse > clock and the captured data. What structure/resources can I use for > this? With a 50 MHz reference clock and adequate setup/hold times, you should be able to do the entire design in that domain and never use the 2 MHz clock as a true clock inside the FPGA. First, all signals will need to be clocked through two FFs to minimize metastability. Unfortunately this adds a 50 MHz clock period of jitter to any relative measurement. With a 25:1 clock rate difference this should not be too much of a concern, but keep it in mind as you perform a timing analysis. Once all signals are sampled into the chip's clock domain you can do a simple edge detection on the incoming 2.048 MHz clock signal to generate a single 50 MHz clock wide, 2.048 MHz enable signal. This will be delayed or the data will be delayed by 50 MHz clock intervals to put your sampling point in the center of your data setup and hold period if it is at all critical. After that you just use the 2.048 MHz enable signal to gate the handling of the data.Article: 106355
Hi Antti, > most of the SOPC magin happens in the perl package "Europe" ASFAIK. > dont expect a lot of information about the internals of the package. That's fine for me. When the connection magic happens and I don't have to care it's fine. OK, one exception: Perhaps I would like to know more details on the latency. The switch fabric is 'plain' VHdL or Verilog. However, generated code is very hard to read. > as very simple example for avalon master-slave type of peripherals there > is on free avalon IP core for SD-card support the core can be found > at some russian forum and later it was also added to the user ip > section of the microtronix forums. Any link handy for this example? > the avalon master is really as simple as the slave. Almost, you have to hold address, data and read/write active as long as waitrequest is pending. I don't like this, see above. In my case e.g. the address from JOP (= top of stack) is valid only for a single cycle. To avoid one more cycle latency I present in the first cycle the TOS and register it. For additional wait cycles a MUX switches from TOS to the address register. I know this is a slight violation of the Avalon specification. There can be some glitches on the MUX switch. For synchronous on-chip peripherals this is absolute not issue. However, this signals are also used for off-chip asynchronous peripherals (SRAM). However, I assume that this possible switching glitches are not really seen on the output pins (or at the SRAM input). MartinArticle: 106356
rickman wrote: > Is self clocking on a single pin possible? What about a synchronisation pulse or word at the begin of every transmission? The fast clock sources a counter, that has to be active, while synchronisation pulse / word is been received. (In other words: The length of the sync pulse / word is measured - the reference time interval.) After this you know (with some error) the frequency of the incoming data stream. All you need is a short time stable (long time unstable) oscillator (RC oscillator). For every transmission a new sync pulse / word is needed. This kind of sync pulse / word is used for RFID transmission from interrogator to tag. With a manchester encoded data stream it is furthermore possible to stay synchronized. During reception the sync machine may work too and if a data symbol is received that has equal length to the reference time interval the new measured length of this symbol may be used as new (re-synchronized) reference time interval. The disadvantage: You need a fast clock - fast enough for even your highest data rates. RalfArticle: 106357
Todd Fleming wrote: > The first two examples produce 16 4-input LUTs on a Spartan 3 and the > third produces only 8 4-input LUTs. Is there a way to get ISE to use > only 8 LUTs without adding flipflops or resorting to a structural > (XORCY, MUXCY, etc.) description? > module adder_test_8_luts(clk, a, b, c, result); > input clk; > input[7:0] a, b; > input c; > output[8:0] result; > > reg[8:0] inv_b; > always @(posedge clk) inv_b <= ~b; > > assign result = a + inv_b + c; > endmodule I strongly guess that the flipflop has normal and inverted output. Therefore you get the inversion for free (for the cost of these flipflops). And furthermore it seems to be, that the pure combinational solutions are slightly to complex to fit into 8 LUTs (the inversion is too much to fit). RalfArticle: 106358
rickman wrote: > jai.dhar@gmail.com wrote: > > Hey guys, > > > > I'm having trouble getting started with my first clock-domain crossing > > task. I need to take in 2 signals; a 2.048M clock and associated data > > stream, and transfer it to a 50M stream that outputs a single-pulse > > clock and the captured data. What structure/resources can I use for > > this? > > With a 50 MHz reference clock and adequate setup/hold times, you should > be able to do the entire design in that domain and never use the 2 MHz > clock as a true clock inside the FPGA. First, all signals will need to > be clocked through two FFs to minimize metastability. Unfortunately > this adds a 50 MHz clock period of jitter to any relative measurement. > With a 25:1 clock rate difference this should not be too much of a > concern, but keep it in mind as you perform a timing analysis. > > Once all signals are sampled into the chip's clock domain you can do a > simple edge detection on the incoming 2.048 MHz clock signal to > generate a single 50 MHz clock wide, 2.048 MHz enable signal. This > will be delayed or the data will be delayed by 50 MHz clock intervals > to put your sampling point in the center of your data setup and hold > period if it is at all critical. > > After that you just use the 2.048 MHz enable signal to gate the > handling of the data. The task isn't that clear, but a 2.048MHz clock makes me suspect there is a serial data stream clocked at 2.048MHz that then is to be retimed onto a 50MHz clock. In this case, there are a number of solutions, but a more definitive statement is required. 2.048MHz is, of course, a very common clock in PCM type applications as used in voice processing. I *think* the OP is asking how to retime (maintaining the framing) a serial data stream from one clock domain to another. Cheers PeteSArticle: 106359
aijazbaig1@gmail.com wrote:
> First of all, you removed the line where I associated the component
> muxc with the entity mux. Inspite of that it worked. Is it because your
> component and entity name were the same? Is this a kind of a rule
> wherein if the names of the component and the entity are the same then
> we need not explicitly link the entity with the given component?
Yes, the default binding rule, but I find
this as confusing as you did.
I prefer to eliminate the component completely
and instance work.mux directly, like this:
architecture testbench of tb_mux is
signal a,b,c : std_logic_vector(7 downto 0);
signal sel : std_logic_vector(1 downto 0);
begin
M1: entity work.mux
port map (a => a, -- IN
b => b, -- IN
sel => sel, -- IN
c => c); -- OUT
> Secondly when we use the port map clause the arguments are actually
> passed and substituted position-wise in the component right?
Yes, that works, but I like the full mapping as above.
Renaming the signal identifiers as a_s etc. is clearer still:
port map (a => a_s, -- IN
b => b_s, -- IN
sel => sel_s, -- IN
c => c_s); -- OUT
-- Mike Treseler
Article: 106360rickman wrote: > If I am going to require a time reference at the receiver the simplest > scheme I know of is just async serial data with a start and a stop bit. > No point in using Manchester encoding if I am transferring the data > over a wire just a few inches long. A serial data protocol like RS232 needs exact timing on sender and receiver side. With the 1-wire protocol you need only one exact clock from the master, the slave can use inexpensive RC components for timing and clock. I've just implemented a VHDL program for reading the unique id of the DS2432, which sits on my Spartan 3E starter kit. Some real-time logic analyzer data: http://www.frank-buss.de/tmp/1wire.png As you can see, the timing precision of the device can varying by nearly a factor of 2 and it would be still possible to communicate with it. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106361
rickman wrote: > Actually, decoder is a misnomer since it will have to both send and > receive. So I don't see any way to get around the need for a timing > reference, either on a pin or by supplying an oscillator. Most likely > it will be on a pin. Right now I like the idea of using I2C, but I > will need to perform a detailed analysis of the tradeoffs vs. standard > async with separate clock, I2C, SPI and Manchester encoding. I see > there are some very small packages for CPLDs, but they don't have much > logic in them. I don't know if I can design such a transceiver in 64 > logic cells. Maybe you could use a microcontroller, like the MC9S08 from Freescale, which I've used in a project: It is inexpensive, has A/D converters integrated, so you don't need to use extra analog pins for the discrete signals, I2C is implemented in hardware on the controller and it is about 1cm^2 wide, so it should fit in a cable (no other external components are required, because it has lots of flash integrated and can generate the system clock internally, if you don't need crystal precision). Then the four pins of the cable would be: Vdd, Vcc, I2C data, I2C clock. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106362
On 12 Aug 2006 04:12:43 -0700, rickman <spamgoeshere4@yahoo.com> wrote: >Actually, that is not correct. Here are two sequences sampled at 1 >MHz. Please tell me the clock rates. > >0101010101010101 >0011001100110011 I can't because (a) I don't know whether the data stream is too fast for me to measure with 1MHz, and (b) assuming there is no aliasing going on, both streams have no data transitions in them. I carefully pointed out in my post the need for (a) sufficiently fast sampling, and (b) a variety of bits in the data stream. >But I acknowledged that you could "measure" the data rate as long as >the bit stream allows for that. And surely, if I can measure it, I can then demodulate it? [...] >Pulse position and pulse with modulation still require a time >measurement which requires me to have a time reference on the receiver. I don't really know what you mean by "a time reference". My point about measurement is that you can demodulate ANY data rate up to some upper limit determined by the time resolution of your receiver, however that may be determined. (There was an interesting discussion about the relationship between that limit and the resolution - is the maximum data rate 1/3 or 1/4 of your clock rate??? - but that doesn't affect my argument.) You don't need any prior knowledge of the data rate whatsoever, except to be sure that it's slower than your upper limit. >If I am going to require a time reference at the receiver the simplest >scheme I know of is just async serial data with a start and a stop bit. > No point in using Manchester encoding if I am transferring the data >over a wire just a few inches long. Do I infer that you're looking for a scheme in which the clock can be extracted with NO timing components at all in the receiver, i.e. by combinational decoding of the data line? If so, I'm pretty sure it can't be done with any 2-level line discipline; but as soon as you permit 3-level signalling, I think it's possible. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 106363
Frank Buss wrote: > http://www.frank-buss.de/tmp/1wire.png I've added it, with some more explanation, to the Wikipedia page: http://en.wikipedia.org/wiki/1-Wire -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106364
PeterC wrote: > I have two clocks which are relatively synchronous (ie. the > frequencies are exactly the same because the originate from > the same master clock), but one of the clocks is shifted in > phase, and this phase shift is dynamically variable and may > be up to one whole period. > > I need to switch between these two clocks, but without losing > rising edges. In that case, it's impossible, because two edges from the two clocks can be arbitrarily close together. Like other respondents, I too have done telecom applications that needed hitless switching between streams that are frequency-locked but not phase-locked. The answer involves passing at least one of the clock+data streams through an elastic buffer in order to realign their phase before trying to do the switching. A 3-bit elastic buffer will allow just shy of 2 unit intervals of peak-to-peak wander before causing a hit. If this is the sort of thing you need, I can dig up an implementation for such a buffer that requires about 7 flip-flops and a handful of gates. -- Dave TweedArticle: 106365
Hi, I was wondering if someone who has used the embedded MAC's can give me a pointer here. I am using BaseX mode, with RocketIO to interface to a a fibre SFP module then via fibre to a syskonnect card in a PC. I have finally got my rocketIO working, after a lot of messing around with all the settings and everything is working, or so it seems. However I am having trouble getting the MAC to auto-negotiate. The PC on the end of the fibre is sending the negotiation frames, and I have a little embedded controller that is poking the MAC host interface configuration registers to set stuff like the MDIO clock divider and such like. Once that register is poked with a sane value I can see the MAC's tx data also switch from sending idle frames to sending negotiation frames and a few clocks later the CLIENTANINTERRUPT signal goes high. At this point I assume they have negotiated? Or am i being silly? But how do you then switch to normal data mode? (The PC at the other end also stays in auto-negotiation mode too) Do I have to read/poke one of the registers in the host interface or MDIO interface? Anyone offer any hits with using these things? Cheers.. BTW The code is based on the v4.1 wrapper, with the patches mentioned in the various xilinx online docs. -- /\/\arc Kelly ..Just your average physicist trying to get by in a world full of normal people...Article: 106366
Hello Mike. Thnks for letting me know that there are some people like myself who prefer clarity and simplicity. I know that VHDL - 93 allows one to completely do away with components but incase of VHDL - 87 , are we allowed to reference an entity directly as you did. So what would M1 be in such a case as you did. Normally M1 can be called an instant of the component in the "normal" case when we instantiate components but now as you haven't declared any components then what does M1 stand for. As far as I know we cannot have instances of entities (or can we??). Its getting a lil confusing here. would you kindly elaborate. Secondly with regards to using the full mapping, do we have to place the target signals on the right hand side of the "=>" operator inside the port map clause brackets? Does this matter at all? Hoping to hear from you soon, Best Regards, Aijaz Baig. Mike Treseler wrote: > aijazbaig1@gmail.com wrote: > > > First of all, you removed the line where I associated the component > > muxc with the entity mux. Inspite of that it worked. Is it because your > > component and entity name were the same? Is this a kind of a rule > > wherein if the names of the component and the entity are the same then > > we need not explicitly link the entity with the given component? > > Yes, the default binding rule, but I find > this as confusing as you did. > > I prefer to eliminate the component completely > and instance work.mux directly, like this: > > architecture testbench of tb_mux is > signal a,b,c : std_logic_vector(7 downto 0); > signal sel : std_logic_vector(1 downto 0); > begin > M1: entity work.mux > port map (a => a, -- IN > b => b, -- IN > sel => sel, -- IN > c => c); -- OUT > > > Secondly when we use the port map clause the arguments are actually > > passed and substituted position-wise in the component right? > > Yes, that works, but I like the full mapping as above. > Renaming the signal identifiers as a_s etc. is clearer still: > > port map (a => a_s, -- IN > b => b_s, -- IN > sel => sel_s, -- IN > c => c_s); -- OUT > > -- Mike TreselerArticle: 106367
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag news:44ddc530$0$11352$3b214f66@tunews.univie.ac.at... > Hi Antti, > >> most of the SOPC magin happens in the perl package "Europe" ASFAIK. >> dont expect a lot of information about the internals of the package. > > That's fine for me. When the connection magic happens and I don't > have to care it's fine. OK, one exception: Perhaps I would like > to know more details on the latency. The switch fabric is 'plain' > VHdL or Verilog. However, generated code is very hard to read. > >> as very simple example for avalon master-slave type of peripherals there >> is on free avalon IP core for SD-card support the core can be found >> at some russian forum and later it was also added to the user ip >> section of the microtronix forums. > > Any link handy for this example? > http://forum.niosforum.com/forum/index.php?showtopic=4430 anttiArticle: 106368
John_H wrote: > You may not notice but I did decode exactly what you show BUT I included the > preceeding and following bits as well. The inversion is the issue. Some > references suggest the bit value is in the first half, some the second. > This is pointed out later in the wikipedia article. I used the first half > of the bit period for the data but you can see my bit half pairs are > correct. First let me say that I am not trying to be rude in any way. If you read my posts and see something that you find offensive, I did not intend that. My comment below about reviewing Wikipedia was meant as a simple statement, not an insult. So I apologize for anything that is perceived as offensive. Please keep in mind that writing is very different from speaking. Since tone can not be conveyed redily words can be interpreted very differently depending on the tone you perceive. For the technical issues... The inversion is not the relevant issue. If you had an algorithm that would decode the stream I gave you as the inverted data I would have accepted that. The problem is the timing. The way Manchester is decoded is to trigger a timer (it was a one shot back when I first worked on this problem) that will ignore any following transitions for approx 3/4 of a bit time. This gives you +-1/4 of a bit time to allow for distortion and jitter in the signal. When you sample the incoming signal with a 3x clock or a 4x clock there are degenerate cases where the signal is sampled at the time it is changing which adds a full clock period to the jitter. In both of these cases there is not enough margin to allow for this an you can get erroneous decoding. Your analysis, if I understood it correctly, produced 6 bits of data when there were only four. I am also interested in the algorithm you used. It would be instructive if you gave us the detail of how you decode the bit stream. Ok, I think I understand where the extra 2 bits came from. Somehow you assumed that the intial and final zeros were adjacent to ones and added extra edges that produced data. So we can ignore those edges and the other data looks good. But what was your algorithm? You need to have a method that can be implemented in logic. I am pretty confident that no matter what algorithm you choose, I can find a case where it won't work. > Of COURSE the sampling doesn't produce an evenly PACED distribution of > pulses, it produces counts of 2 to 4 for the two half bits from adjecent > values and counts from 1-2 for the isolated half bits. It happens that > these overlap as I described. If you only have an all-zero or all-one > pattern then no, you cannot ambiguously extract the data. Once you get any > other data, the alignment is guaranteed. I think you are referring to the initial alignment. Manchester encoding is typically used in systems where the signal is broadcast over a radio or other analog medium which can have timing and amplitude distortions which can introduce erroneous bits. That is typically handled by sending a synchrononization sequence of alternating 1s and 0s. This produces a pattern of transitions only at the bit center to assure proper alignment. The sequences I sent did not include any medium induced distortions, so the initial transition was a bit center and was an appropriate transition to start your process. > You mentioned the sequences need to be decoded to 1001 yet you decoded 1100. > At the 2x transmit output, the encoded sequence would be either 10100101 or > 01011010 depending on your polarity. Is that what you were attempting to > show? Or was it 1100? Yes, the second bitstream produces a wrong pattern because of the jitter introduced. That is my point. You can decode the first bitstream because there is no distortion. But the second bitstream shows that that distortion introduced by sampling on the transition will give errors and can not be avoided with a 3x or 4x clocking scheme. > Your "go back to Wikipedia" comment was uncalled for. If you don't > understand what I'm trying to describe or vice-versa, it's a problem with > the communication medium (to include the inaccuracies of English) and not > that I'm brain challenged. As I posted above, I was not trying to insult you. I was suggesting that you do not understand how to decode a Manchester encoded signal and should check the references. Sorry that it sounded like an insult. I have no reason to insult anyone here and I apologize. > Embedded clocks are used all over. Successfully. But you don't see it. > Are you right? I don't understand what you are saying with this. > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:1155329590.259386.229690@h48g2000cwc.googlegroups.com... > > John_H wrote: > >> "John_H" <newsgroup@johnhandwork.com> wrote in message > >> news:Iu5Dg.7581$Oh1.4082@news01.roc.ny... > >> > >> > 0001101110010000 > >> > 10 01 01 10 10 01 > >> > 1 0 0 1 1 0 > >> > > >> > 0000101111010000 > >> > 10 01 01 10 10 01 > >> > 1 0 0 1 1 0 > > Ok, that is what you are not getting. Time sampling does not produce > > an even distribution of pulses in the time sampled domain with a 3x > > clock. The above sequences both need to be decoded to the same > > sequence, 1001. The first sequence assumes "ideal" sampling with no > > timing abiguities. The second sequence is what you might get if the > > sampling is done right on the important edges and a small amount of > > jitter messes up your data. > > > > 000_1101110010000 > > ^ First bit = 1 > > 00011_01110010000 > > ^ edge between bits, ignore > > 000110_1110010000 > > ^ Second bit = 1 > > 000110111_0010000 > > ^ Third bit = 0 > > 00011011100_10000 > > ^ edge between bits, ignore > > 000110111001_0000 > > ^ Fourth bit = 0Article: 106369
In article <110820062235029049%dmpalmer@email.com>, David M. Palmer <dmpalmer@email.com> wrote: > Gaisler has a nice suite of GPL'd IP for an AMBA-bussed Leon3 (SPARC) > system with Ethernet, DDR RAM, Spacewire, PCI, AES Crypto, and others. > http://www.gaisler.com Following up, I sent this question to Gaisler, and he said: > The board uses a XC3S500 FPGA which about 10,000 cells. > You will be able to fit a minimum leon3 system, but not > much more. One problem is that the board uses 16-bit DDR > memory, but the leon3/grlib DDR controller can only handle > 32-bit memory banks. > > Jiri. So I may have to stick with OpenCores and/or whatever useful components I can extract from the Gaisler cores. -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 106370
PeteS wrote: > rickman wrote: > > jai.dhar@gmail.com wrote: > > > Hey guys, > > > > > > I'm having trouble getting started with my first clock-domain crossing > > > task. I need to take in 2 signals; a 2.048M clock and associated data > > > stream, and transfer it to a 50M stream that outputs a single-pulse > > > clock and the captured data. What structure/resources can I use for > > > this? > > > > With a 50 MHz reference clock and adequate setup/hold times, you should > > be able to do the entire design in that domain and never use the 2 MHz > > clock as a true clock inside the FPGA. First, all signals will need to > > be clocked through two FFs to minimize metastability. Unfortunately > > this adds a 50 MHz clock period of jitter to any relative measurement. > > With a 25:1 clock rate difference this should not be too much of a > > concern, but keep it in mind as you perform a timing analysis. > > > > Once all signals are sampled into the chip's clock domain you can do a > > simple edge detection on the incoming 2.048 MHz clock signal to > > generate a single 50 MHz clock wide, 2.048 MHz enable signal. This > > will be delayed or the data will be delayed by 50 MHz clock intervals > > to put your sampling point in the center of your data setup and hold > > period if it is at all critical. > > > > After that you just use the 2.048 MHz enable signal to gate the > > handling of the data. > > The task isn't that clear, but a 2.048MHz clock makes me suspect there > is a serial data stream clocked at 2.048MHz that then is to be retimed > onto a 50MHz clock. In this case, there are a number of solutions, but > a more definitive statement is required. 2.048MHz is, of course, a very > common clock in PCM type applications as used in voice processing. > > I *think* the OP is asking how to retime (maintaining the framing) a > serial data stream from one clock domain to another. That was exactly what I assumed. Regardless, my approach will do the job in any case. This is what we did in a telecom application I worked on where the data rate varied over a wide range from T1 to OC48, but the clock rate remained the same. We maintained an internal bus width at 32 bits but used a clock enable to allow a very wide range of data rates. Of course the input data and clock were synchronized in just the way I described above. If the serial data is being shifted into an 8 or 32 bit register you just gate the 2.048 MHz enable pulse to only allow every Nth pulse through to produce a 2.048/N MHz enable signal. This approach is very common and not at all hard to understand.Article: 106371
Sylvain Munaut wrote:
> Todd Fleming wrote:
> > module adder_test_16_luts_1(a, b, c, result);
> > input[7:0] a, b;
> > input c;
> > output[8:0] result;
> >
> > assign result = a + (~b) + c;
> > endmodule
>
> Have you tried with
>
> assign result = (~b) + a + c;
>
> ?
>
>
> Sylvain
Oooh, good idea. Trying it now... Whoa! this one used 22! For
reference, here is the 22-LUT version:
module adder_test_22_luts(a, b, c, result);
input[7:0] a, b;
input c;
output[8:0] result;
assign result = (~b) + a + c;
endmodule
Todd
Article: 106372On 11 Aug 2006 14:16:19 -0700, "rickman" <spamgoeshere4@yahoo.com> wrote: >Frank Buss wrote: >> rickman wrote: >> >> > Is self clocking on a single pin possible? I am thinking that the >> > extra info has to be presented in some manner that requires either a >> > timing or amplitude measurement. >> >> As Jim wrote, the one-wire bus can do this. With this concept you need only >> one wire (and ground) to power and communicate with a device: >> >> http://pdfserv.maxim-ic.com/en/an/onewirebus.pdf >> http://www.maxim-ic.com/appnotes.cfm/an_pk/126 > >Thanks to everyone for their posts. Each of the above solutions >require timing of the signal and so will not work without a clock (or >timer) of a specified rate. The key is "specified". To decode a >machester stream you need a time interval of about 3/4 of the bit time >in order to blank the edge detector on the edge between bits. If you *know* it's Manchester coding, and have *no idea* of the clock rate, the problem can be solved if you can afford to spend some time framing up. It's harder if you instantly need to decode the first bit. Basic approach is to measure the times between transitions, compare several successive transition intervals, and classify them as "long" or "short" compared to each other. THEN take a mean value, apply blanking (clock recovery), and start framing up. (If you need to retroactively decode the first bit, you'll need to store and re-visit the first few transition times. This may be easier with the assistance of an embedded CPU) There will need to be some constraints on data, otherwise an infinite sequence of '0's or '1's would take infinitely long to decode. In SP/DIF or EBU/AES digital audio for example, this comes in the form of an extra-long transition interval (1.5 bit times) during a preamble, the trailing edge of which is guaranteed to correctly sync the clock recovery circuit. >So I can't read a Manchester stream at 10 Mbps and one at 1 >Mbps with the same timer. This approach should allow that - given some quiet time between different streams, to enable you to recognise a switch in rate. - BrianArticle: 106373
On 12 Aug 2006 04:12:43 -0700, "rickman" <spamgoeshere4@yahoo.com> wrote: >Jonathan Bromley wrote: >> On 11 Aug 2006 14:16:19 -0700, rickman >> <spamgoeshere4@yahoo.com> wrote: >> >> >> >Thanks to everyone for their posts. Each of the above solutions >> >require timing of the signal and so will not work without a clock (or >> >timer) of a specified rate. >> >> I'm not sure I understand this. >> >> Give me an oscillogram of a Manchester-coded signal and I can >> tell you its clock rate by inspection - unless the data stream >> is all-1s or all-0s, and that's a corner case that we easily >> know how to avoid. I need only one different bit in the >> entire oscillogram and I can work out what's going on with >> no _a priori_ knowledge of the data rate. > >Actually, that is not correct. Here are two sequences sampled at 1 >MHz. Please tell me the clock rates. > >0101010101010101 >0011001100110011 Where are the "different" bits specified by Jonathan in that sequence? These are both sequences of *identical* bits - all 1's or all 0's (when stripped of their clock), which Johnathan already covered. - BrianArticle: 106374
On Fri, 11 Aug 2006 18:27:48 -0400, "MM" <mbmsv@yahoo.com> wrote: >Hi all, > >I have created a custom OPB peripheral template with the wizard and now >trying to make sense of it... I noticed that the wizard included the >opb_ipif_v2_00_h interface. However the EDK directory has all kinds of >versions of the same interface up to v3_01_c... Can someone explain what are >the differences between all of them and why the wizard picked one from the >middle and not the latest? One difference is that 3.01 supports autoincrement addressing, which can be useful for DMA. However, 3.01 is slave only, it does not offer bus mastering capability with an internal DMA controller; that requires 2.xx. This is unfortunate for me, having started with 3.01; I am currently using "opb_central_dma" for DMA transfers. Which double-handles data (reads it from external memory into its own buffer; THEN writes it to my core in a separate operation, taking 2 cycles per word transferred, plus overheads as it only transfers bursts of 16 words at a time. When I want to add keyhole DMA to my core (to transfer data in a single operation) I will have to step back to 2.xx. Anyway my guess is that you asked for OPB bus mastering capability, and the wizard picked the latest core that supports it... Xilinx - what is the reasoning behind this? Where is it clearly explained? Are there any plans for a 3.xx version WITH mastering and DMA support? And why is the autoincrement addressing (burst mode) in 3.01 limited to maximum 16 words per burst? - Brian
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