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 schrieb: > Antti wrote: > > Hi > > > > V4FX Linux 2.6 by end of Aug 2006 > > MB uClinux 2.6 by Dec 6 2006 > > by > > http://www.lynuxworks.com > > both will be pushed to open/GPL linux tree > > > > thats the current schedule from Xilinx > > > > --- > > for those who are interested then the new ver 5 MicroBlaze is fully > > compatible to ver 4 - I have tested with "old" uClinux 2.4.x images > > they run succesfully in MicroBlaze v5 based systems (in Virtex-4 > > targets). > > > > Official support for Virtex-5 MicroBlaze (ver 5) will be included in > > EDK 8.2 SP2 > > > > Xilant XSIM simulator supporting MicroBlaze (and capable to run > > different uClinux versions) will shortly be available (Xilinx VP > > simulator currently does not succesfully boot uclinux). > > Thanks Antti. > Any info on what has changed in V5 MB ? > > ( or is V5 just a tweak to have a compile-time variant that runs better > on the V5 silicon ? ) > Do you know if WebPACK users will be able to evaluate this, at least on > V4 silicon ? > > [I guess not on V5 silicon, as WebPACK specifically excludes that ?] > > -jg MB v5 compiles ok for recent FPGAs eg s3/e, V4, etc. having webpack and EDK 8.2 you can eval MB v5. MB v5 Virtex-5 support is officially coming in EDK 8.2 SP2 AnttiArticle: 106326
rickman wrote: > I was posting to the thread on the embedded clock in a Manchester > encoded bit stream and realized that the clock is not truely embedded > in the data stream. I say this because you still have to know the > clock rate in order for it to work. The decoder has to lock out the > edge detection for the time between bits to prevent detecting false > bits. You have to know the data rate in order to time this lock out > period. Of course the timing is much less critical than a typical > clock, even an RC clock. But none the less you have to have a clock of > a given frequency. > > Are there any methods of transmitting data and clock on a single wire > that do not rely on the decoder having knowlege of the clock rate. > This is not entirely academic. I have an interface I am working on > where I need to multiplex multiple signals over a single pin. One is a > serial bus and the others are discrete pins which require very accurate > timing. Which means what, exactly ? fs ? Idealy the decoder would not have a clock, but rather the data > would be self clocking. I would like to use a very low power CPLD that > could be powered by either the signal or at least only require a few mA > of current from an LDO on the battery connection. > > 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. The closest to this would be PWM modulation, widely seen on 1-wire BUS designs. Intel have a SST bus, that has up to 2MBd PWM, but info is sparse. To demodulate PWM, you need only a dual monostable (or, a Single gated RC Osc + small divider ), and that Osc can Auto-start, so can idle in very low power states. Normally two time-slots are used, one monstable at 50% bit time, samples the data, and another is set to timeout after no-edges for XX time, which does the frame operations. With a CPLD, you control both, and can send using SPI with a good fifo ( you need to ensure no false frames, due to host pauses ) -jgArticle: 106327
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 -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106328
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
>
> I may have inverted my single-bit results. It looks like manchester has the
> logic level in the second half of the bit, not the first like I thought. I
> checked wikipedia.org and saw my inversion, otherwise the idea still holds.
>
> Without knowing the clock rate, Manchester encoding has pulses that are
> either 1/2 bit period or 1 whole bit period. You should get two tight
> ranges of count values that correspond to these intervals. In the 3x clock
> case, those two ranges overlap. It's knowing when the half bit periods are
> definitely half or whole bit periods that the alignment can be determined
> and the frequency extracted without ambiguity.
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 = 0
If you don't understand how this was decoded, you need to go back to
Wikipedia.
The second sequence has two places where the signal capture was on the
wrong side of the edge because of jitter. So it now is not possible to
decode and recover the correct data. The same thing can happen with a
4x clock. But as the clock gets faster than 4x there are no more
multiples where you can't find a correct delay for ignoring the
inter-bit edge.
Article: 106329Frank 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. That interval can be somewhat broad, but must be known to at least better than 33%. So I can't read a Manchester stream at 10 Mbps and one at 1 Mbps with the same timer. Of course I can design a circuit that will synchronize the clock to a fixed rate bit stream. But that is a lot more complex. I am looking for something that will just plain clock the data across the interface without a requirement to know the frequency whether by measuring it, or a priori.Article: 106330
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. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106331
Hi, I am trying to interface a keyboard with the Xilinx Dio5 board ps2
port using EDK(c dev kit). From my understanding, the keyboard sends
out a low for 50ms(or whatever time) before it sends the scan code. I
am confused on how i poll for this 50ms time. Do i put it in my main{}
code to poll everytime for this scan code or does the keyboard have
some sort of interrupt? In addition, do i have to map every single key
manually or is there another way? Thanks!
Article: 106332rickman 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. That > interval can be somewhat broad, but must be known to at least better > than 33%. So I can't read a Manchester stream at 10 Mbps and one at 1 > Mbps with the same timer. Of course I can design a circuit that will > synchronize the clock to a fixed rate bit stream. But that is a lot > more complex. I am looking for something that will just plain clock > the data across the interface without a requirement to know the > frequency whether by measuring it, or a priori. Why do you need such a loose frequency spec ? ALL schemes will clearly need some time-element. What you need is to reduce the Clock _tolerance_ and _power_ costs, to minimal levels. The one-wire (PWM data) designs change from a classic clock (which draws power all the time ) to a more async-based monostable ( so can idle at very low powers ). It also drops the clock tolerance to quite slack levels, met by the cheapest components. The overhead, is slightly less bandwidth efficency than other modulation methods. With one wire, the master provides the edges, and the slave the data (sometimes), and the slave can use very cheap / low power / fast wakeup RC oscillator. one-wire designs are implicitly duplex, and so are better suited than manchester to low cost slave nodes. They also work well with CAN transcievers, as that is a 'OR' BUS -jgArticle: 106333
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. 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. 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? 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. Embedded clocks are used all over. Successfully. But you don't see it. Are you right? "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 >> >> I may have inverted my single-bit results. It looks like manchester has >> the >> logic level in the second half of the bit, not the first like I thought. >> I >> checked wikipedia.org and saw my inversion, otherwise the idea still >> holds. >> >> Without knowing the clock rate, Manchester encoding has pulses that are >> either 1/2 bit period or 1 whole bit period. You should get two tight >> ranges of count values that correspond to these intervals. In the 3x >> clock >> case, those two ranges overlap. It's knowing when the half bit periods >> are >> definitely half or whole bit periods that the alignment can be determined >> and the frequency extracted without ambiguity. > > 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 = 0 > > If you don't understand how this was decoded, you need to go back to > Wikipedia. > > The second sequence has two places where the signal capture was on the > wrong side of the edge because of jitter. So it now is not possible to > decode and recover the correct data. The same thing can happen with a > 4x clock. But as the clock gets faster than 4x there are no more > multiples where you can't find a correct delay for ignoring the > inter-bit edge. >Article: 106334
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 ;-)
So if you are interested to give a Java processor in the SOPC
environment a try...
There is are two ready to use Quartus projects available: a generic
version for a 256Kx16 SRAM and a version for the Altera DE2 board [3].
If you have the DE2 board follow the steps to build JOP:
1. check out the actual sources from opencores
cvs -d :pserver:anonymous@cvs.opencores.org:/cvsroot/anonymous -z9 co -P jop
2. Open the Quartus project .../quartus/altde2/jop.qpf
3. Start Tools - SOPC Builder...
4. Press Generate
5. Press Exit and close Quartus
6. Edit the following lines in the Makefile:
BLASTER_TYPE=USB-Blaster
QPROJ=altde2
7. and then run the usual make
.... and it should run the Java/JOP Hello World ;-)
A detailed design flow document (without the SOPC builder part) is
available at [4].
What's cool for me: I get the SDRAM controller for free and
have a JOP system with 8 MB! Now it's time to write some 'big'
embedded Java applications ;-)
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...
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 :-(
So, happy JOP SOPC building,
Martin
[1] http://www.altera.com/products/software/products/dsp/dsp-builder.html
[2] http://www.jopdesign.com/
[3] http://www.altera.com/education/univ/materials/boards/unv-de2-board.html
[4] http://www.jopdesign.com/doc/build.pdf
[5] http://www.opencores.org/projects.cgi/web/simpcon/overview
Article: 106335Hi 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? Thanks, /MikhailArticle: 106336
OK, I have looked in the sources. It is pretty clear what the differences are, what is still not clear is why the wizard is 2 generations behind... /Mikhail "MM" <mbmsv@yahoo.com> wrote in message news:4k4eekFafp1sU1@individual.net... > 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? > > Thanks, > /Mikhail > >Article: 106337
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: 106338
Martin Schoeberl wrote: > 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? > 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". > 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. TommyArticle: 106339
Please let me be moderator, for this is interesting. Let's simplify the discussion by assuming no jitter and no glitches. Lets also agree that Manchester code is ambiguous in an all-1 or al-0 transmission, since they look identical. The decoder needs a 0-1 or 1-0 bit transition in order to start on the "right foot". That is all well-known. The question then is: Can Manchester Code be decoded with the help of a local clock that is, for example, exactly 3 times the bit rate, or are there severe limitations on the local clock frequency. The simple approach that triggers on a transition and then suppresses the next one, if it occurs at half-bit time, has a problem with a local 3x asynchronous decoding clock. John suggests a solution, and Rickman does not accept it. Round 2: Peter AlfkeArticle: 106340
Brandon, In addition to the From-To suggested by Gabor, you can also use the DATAPATHONLY keyword to keep the clock phase differences (which could vary from build to build depending upon your design) out of the calculation. Check out the Constraints Guide: http://www.xilinx.com/support/sw_manuals/xilinx82/download/cgd.zip for more information. Best regards, Ryan Laity Xilinx FAE Brandon Jasionowski wrote: > Correct. I'm using the CLK0 and CLKFX outputs from the same DCM. The > prior is writing, the latter is reading from the asynch FIFO. > > Oh well, this is a pain. Maybe I can find something better, or just > assume it works. > > Gabor wrote: >> This is an issue with ISE that tries to be too smart about related >> clocks, i.e. clocks derived from the same source. I'm guessing that >> your two clocks are related via a DCM? >> >> You can add a FROM TO style of timespec calling out the two >> clocks and give it a sufficiently large value that these cross-clock >> paths are essentially ignored. >> >> something like (in the .ucf file): >> NET "fx_clk" TNM="FastFlops"; >> NET "CLK_OSC" TNM="SlowFlops"; >> TIMESPEC "TS_fastslow"=FROM "SlowFlops" TO "FastFlops" 15 ns; >> >> >> Brandon Jasionowski wrote: >>> I am having a hard time getting ISE/XST to ignore clock skew between >>> two clock domains from an asychronous FIFO generated from CoreGen. Why >>> is the tool not ignoring this automatically? Here is the error after >>> Map: >>> >>> <SNIP> >>> ================================================================================ >>> Timing constraint: TS_CLKFB_OSC = PERIOD TIMEGRP "CLKFB_OSC" TS_CLK1_FB >>> HIGH 50%; >>> >>> 1681 items analyzed, 26 timing errors detected. (26 setup errors, 0 >>> hold errors) >>> Minimum period is 3892.500ns. >>> -------------------------------------------------------------------------------- >>> Slack: -1.036ns (requirement - (data path - clock path >>> skew + uncertainty)) >>> Source: >>> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 (FF) >>> Destination: >>> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 (FF) >>> Requirement: 0.002ns >>> Data Path Delay: 1.038ns (Levels of Logic = 0) >>> Clock Path Skew: 0.000ns >>> Source Clock: fx_clk rising at 9607.498ns >>> Destination Clock: CLK_OSC rising at 9607.500ns >>> Clock Uncertainty: 0.000ns >>> Timing Improvement Wizard >>> Data Path: fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 to >>> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 >>> Delay type Delay(ns) Logical Resource(s) >>> ---------------------------- ------------------- >>> Tcko 0.568 >>> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 >>> net (fanout=1) e 0.100 >>> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp<8> >>> Tdick 0.370 >>> fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 >>> ---------------------------- --------------------------- >>> Total 1.038ns (0.938ns logic, 0.100ns route) >>> (90.4% logic, 9.6% route) >>> </SNIP> >>> >>> I have a 9.5 ns clock input feeding the write port, and a 9.5*21/19 ns >>> clock on the read port. I have a TIG setup as follows: >>> >>> <SNIP> >>> NET "CLK1_FB" TNM_NET = "CLK1_FB"; >>> TIMESPEC "TS_CLK1_FB" = PERIOD "CLK1_FB" 7.5 ns HIGH 50 %; >>> PIN "U0_DCM.CLK0" TNM = "DCM_CLK0"; >>> PIN "U0_DCM.CLKFX" TNM = "DCM_CLKFX"; >>> TIMESPEC "TS_CLK0_2_CLKFX" = FROM "DCM_CLK0" TO "DCM_CLKFX" TIG; >>> #Asynch FIFO clock domains >>> </SNIP> >>> >>> CLK1_FB drives the CLKIN input of the DCM, so it too is 9.5 ns. Any >>> ideas? I'm lost.... >>> >>> Thx, >>> -Brandon >Article: 106341
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? Thank you kindly, JaiArticle: 106342
Phil wrote:
> Hi, I am trying to interface a keyboard with the Xilinx Dio5 board ps2
> port using EDK(c dev kit). From my understanding, the keyboard sends
> out a low for 50ms(or whatever time) before it sends the scan code. I
> am confused on how i poll for this 50ms time. Do i put it in my main{}
> code to poll everytime for this scan code or does the keyboard have
> some sort of interrupt? In addition, do i have to map every single key
> manually or is there another way? Thanks!
I would suggest writing a PS/2 interface, or adapting an existing one.
You really don't want software manually handling a slow peripheral like
a keyboard or mouse. I have a PS/2 UART core that just handles
recieving and transmitting - you have to implement scancode conversion
and keyboard/mouse state in higher level logic or software.
Note, you can use a ROM to handle the scancode conversion to ASCII, if
all you need is text. Simply pass your scancode into the ROM as the
address, and take the output of the ROM as your data. I would suggest,
at a minimum, keeping track of the shift key. Use a state-bit as an
additional input to your ROM, so you can provide both shifted, and
non-shifted, characters.
Article: 106343Be more specific. What does "transfer it to a 50M stream that outputs a single-pulse clock and the captured data" mean? 50 MHz? How often? Peter Alfke ================ 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? > > Thank you kindly, > > JaiArticle: 106344
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 There is a nice configuration program that lets you select the modules you want. However, the configuration program etc. has to be configured to tell it the details of the board, what PHY and RAM it has, and you need a .ucf file. Has anybody done this for this board yet? Alternatively, has anybody put together a complete opencores project for this board with the Wishbone bus, a processor, RAM, Ethernet, and other things that they could share? There are lots of nice little pieces in OpenCores, but I don't see good documentation and examples for putting it all together. -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 106345
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_16_luts_1(a, b, c, result);
input[7:0] a, b;
input c;
output[8:0] result;
assign result = a + (~b) + c;
endmodule
module adder_test_16_luts_2(a, b, c, result);
input[7:0] a, b;
input c;
output[8:0] result;
wire[8:0] inv_b = ~b;
assign result = a + inv_b + c;
endmodule
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
Todd
Article: 106346bart wrote: >>While for Xilinx parts I can go the the Digikey or Nuhorizont webpage (and >>even www.schukat.de carries some XC3Sparts) and get online quote and >>availablity, I don't know of such places for Lattice parts. >> > > Hello Uwe, > You might try a specialized distributor such as Mouser for smaller > quantities of Lattice parts. It is my understanding that proto > quantities are their specialty, so they are setup to have stock on hand > of FPGAs and a very low minimum order qty (1pc.?). If you're interested > in Mouser, they do stock Lattice FPGAs: > > http://www.mouser.com/latticesemi/ > > Hope this helps. > Regards, > Bart Borosky, Lattice > What about small order quantities in the U.K?Article: 106347
Hello. Tried the program which you had submitted. Worked correctly.However I have certain doubts which I'd like to clear. 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? Secondly when we use the port map clause the arguments are actuallp passed and substituted position-wise in the component right? Well this is kind of confusing. Please elaborate. Hoping to hear from you soon, Aijaz Baig. aijazbaig1@gmail.com wrote: > Hello . > I made the corrections as suggested. I used the library and the use > clauses before each entity declaration and also took care of the > component error as mentioned. > Now the only error I get is that it says that > "Enumeration literal 'Z' is not of type std_logic_vector." and the > compiler exits. The 'others' clause assigns each element of the array > to Z which is of type std_logic and the array C is indeed an array of > std_logic elements. So why is the compiler flagging an error. > > Hope to hear from you. > Best Regards, > Aijaz Baig. > ALuPin@web.de wrote: > > Hi, > > > > different errors, have a close look at the following corrected code: > > > > library ieee; > > use ieee.std_logic_1164.all; > > > > > > entity mux is > > port(a,b:IN std_logic_vector(7 downto 0); > > sel:IN std_logic_vector(1 downto 0); > > c : OUT std_logic_vector(7 downto 0)); > > end mux; > > > > > > architecture example of mux is > > begin > > process(a,b,sel) > > begin > > if(sel = "00") then > > c <= "00000000"; > > elsif (sel = "01") then > > c <= a; > > elsif (sel = "10") then > > c <= b; > > else > > c <= (OTHERS => 'Z'); > > end if; > > end process; > > end example; > > > > > > > > > > ---------------------------------------------------------------------------------------------------------------- > > > > library ieee; > > use ieee.std_logic_1164.all; > > > > entity tb_mux is > > end entity; > > > > > > architecture testbench of tb_mux is > > signal a,b,c : std_logic_vector(7 downto 0); > > signal sel : std_logic_vector(1 downto 0); > > component mux is > > port(a,b : in std_logic_vector(7 downto 0); > > sel : in std_logic_vector(1 downto 0); > > c : out std_logic_vector(7 downto 0)); > > end component; > > > > begin > > M1:mux port map(a,b,sel,c); > > process > > begin > > a <= X"11" after 1 ns, > > X"AF" after 2 ns, > > X"BB" after 3 ns, > > X"6F" after 4 ns; > > > > > > b <= X"01" after 1 ns, > > X"2F" after 2 ns, > > X"3C" after 3 ns, > > X"BE" after 4 ns; > > > > > > sel <= B"00" after 1 ns, > > B"01" after 2 ns, > > B"10" after 3 ns, > > B"11" after 4 ns; > > wait; > > end process; > > end testbench;Article: 106348
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. 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. 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! -- 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: 106349
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_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
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