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
Hi Rémy,
Can you provide me with the MicroBlaze configuration settings (or the whole
.mhs file)?
It looks like you get a hardware exception but you don't have a exception
handler.
What hardware exceptions have you enabled on MicroBlaze?
Göran
"Rémy" <thomasrt2008@gmail.com> wrote in message
news:f6cbd175-5bc5-4a9a-9b64-5e8a1b386299@e6g2000prf.googlegroups.com...
Hi,
I just try the patch http://www.xilinx.com/support/answers/30051.htm
and the bug steal occurs if I have a "rand" or "srand" function in my
code.
When i stop the CPU under XMD it returns me the same adress:
0x820036a4
if i do "mb-objdump -x -D -S -t executable.elf > dump.out" to output a
dump file of my *.elf to see what there is at this address:
.section .text
.align 2
.ent _hw_exception_handler
_hw_exception_handler:
bri 0;
820036a4: b8000000 bri 0 // 820036a4
so apparently the code is crashed because of an exeption like the
problem in "Answer Record #29784 (http://www.xilinx.com/support/
answers/
29784.htm". Although i work on the last version of tools with the SP2
and the last patch....
I have tried my code on a PowerPC architecture with the same IP on the
same Hardware and I don't have the bug.
Rémy
Article: 129726On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > I have written a process to generate random numbers using UNIFORM. I > was trying to check the results using "rand" in matlab. How do i > initialise the seed values of both these functions to the same value. > I see that the random numbers generated by UNIFORM are different > compared to rand when the seed values are left uninitialised. > What do I need to change so that I get same output from both programs. > > Thanks Uninitilised positives (the seeds in this case) will take a value of 1 when they are put into the uniform function. Unitialised types when used will take type'low as their value positive'low = 1 std_logic'low = 'u' etc. so both of your first calls to uniform are seeding it with two 1s. I dont know how the seeding works in matlab. It may not even use positives, but the entire integer range. it is common in C to seed the random number generator with the system time. Does matlab do something similar? The C random function only has 1 seed, whereas uniform takes 2.Article: 129727
Antti <Antti.Lukats@googlemail.com> writes: > 3) Lattice ECP2 have non-volatile AES key, making them best candidate > if design security/theft is of concern, also the design migration from > Xilinx to Lattice is much much more easier then Xilinx to Actel If it's non-volatile, is it not "relatively easy" to extract the key from the chip by invasive methods? I say "relatively", compared to the volatile keys in a virtex device - still not a trivial task :-) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 129728
That is a simple question: It is a device to measure the timing of input signals. We have 25ps resolution now and want to improve on that. The problem ist that we can only fit 8 inputs on any board. Most customers need only less than 8 channels, but some need a lot more. These are important customers, but the volume is really low, so we would rather use a standard backplane with our standard boards. Kolja On 3 Mrz., 19:43, austin <aus...@xilinx.com> wrote: > Kolja, > > I hate to say it, but why do you wish to architect a system that has > this requirement? Why not solve the problem in a way that does not > require this 50ps phase alignment? The added FIFO buffering may be well > worth the pain of precise clock phase control/signal integrity. > > My two pennies, > > AustinArticle: 129729
That is OK. We definitely will have jitter cleanup PLLs on the boards. I am not looking for a passive solution because I want a simple or cheap solution, but because I am worried by the temperature dependant delay of the active components. Kolja On 3 Mrz., 22:54, "MM" <mb...@yahoo.com> wrote: > Kolja, > > You could distribute some slow clock and generate your fast clocks on each > board independently with high quality PLLs but that's not a pure passive > solution you've asked for... > > /MikhailArticle: 129730
On 3 Mrz., 18:45, "Symon" <symon_bre...@hotmail.com> wrote: > 1) What frequency is the clock? The higher the frequency, the more likely > you are to have problems with reflections from an edge during the next edg= e. And otherwise you think I can get a clean enough edge across 10 stubs? (or 5 using Peters suggestion). The setup is rather complex for a simulation. > 2) What is the rise time of the clock? The faster the rise time, the bigge= r > the reflections, in general. Well, fast risetimes is a way to reduce phase shifts due to variations in threshold and supply voltage. So currently I am looking into very fast rise times. > 3) What logic standard is the clock? Free to choose. I am looking at CML and LVDS currently. > 4) What does the clock drive on the destination cards? FPGAs have relative= ly > large pin capacitance which can cause big reflections at fast edge rates. Good point, I did not think of that. Maybe external clock buffers on the inputs could improve on that. > Your 50ps requirement rules out any tricks with DCMs, they have that much > phase noise and more already. Even external zero delay buffers often have something like 200ps skew. > I like your daisy chain plan. As you are worried about 50ps, this must be > the safest way to go. You could use something like the SY58011u 1:2 CML > buffer from Micrel, depending on your operating temperature range. The > datasheet has a graph of propagation delay versus temperature. From 10C to= > 80C the delay changes by 10ps more or less linearly. If you can keep the > temperature range low, this might be ok. Use one output to drive the board= , > the other to drive the next board. They also make 1:4 parts, so the first > board could drive the next 3, the 4th drives 5,6,7 and so on. So you'd hav= e > fewer buffers. That is a great suggestion. I had a look at multiple parts but only one of those specified the temperature effect - which was to big. 10ps over 70=B0C is rather good. The linear solution has the advantage that it is easy to make all boards identical. > Oh, yeah. Simulate it! *sigh* It's a big task for simulation. But I probably will have to.Article: 129731
In article <xnr6era4pd.fsf@delorie.com>, DJ Delorie <dj@delorie.com> writes: |> |> I keep wondering if there's a market for a few "unbalanced" devices, |> like something with a ton of gates but in a tqfp-64 package. I bet there is, although probably not a high numbers market -- but anyone dealing with repairing long-gone legacy devices would love such beasts, especially when they come with a separate V_I/O input where one could adjust the logic level to stone-age (5V, 3.3V) -- heck, make at least two voltage domains for easy interfacing -- without the need for external drivers and level shifters. And don't forget the internal configuration PROM. Ok, make that thing reasonably priced and you probably have an ASIC killer for modest-run "single chip plus some little discrete" stuff, like e.g. the C64DTV (IIRC 250.000 units were produced). Rainer (practicing geriatronician)Article: 129732
On 3 Mrz., 18:23, John_H <newsgr...@johnhandwork.com> wrote: > On Mar 3, 8:27 am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > > > Hi, > > > maybe you folks can help me with a design decision: > > > I need to distribute a clock to up to ten identical boards. > > The boards are all plugged into a backplane in a single row. > > > In addition to the backplane the boards will be connected by > > a twinax flatband cable on samtec connectors. For the clock > > distribution I can choose between a bus structure cable or a > > series of point to point connections between neighbouring boards. > > > The leftmost of the identical boards shall provide a clock for all > > the other boards. I am now concerned that a bus structure with > > that many stubs will have problems maintaining a good signal quality. > > > I could instead use point to point connections with fanout clock > > buffers on each board to forward the clock to the next board. As far > > as the signal quality goes this will obviously work very well, > > BUT the boards need a fixed phase relationship. While the absolute > > phase is of no importance, the phase must not drift over time or > > temperature by more than 50ps or so. Ten buffers in a row would > > probably have a larger drift, wouldn't they? > > > Any ideas, how I can make a pure passive distribution work in a setup > > like that? > > > Also: How can I turn on the termination on the last board dynamically? > > > Kolja Sulimma > > Kolja, > > Have you considered using a clock buffer on the backplane? By using > point-to-point connections, your design is significantly cleaner but > you no longer have a passive-only backplane solution. > > - John_H That would work, but than we need custom made backplanes. An intermediate solution is to have one special board that provides ten clock lines and then shifting the clock lines by one on each board. Of course this clogges 20 lines on the cable. Kolja SulimmaArticle: 129733
> Sinus(1Khz)----> ADC-->FPGA--->DAC--->Sinus(1Khz) > Ich kann schon etwas am Ausgang (nach der DA-Wandler) mit dem > Kopfh=EF=BF=BDrer > h=EF=BF=BDren. Allerdings k=EF=BF=BDnnte ich das mit dem Oszilloskop nicht= messen . Vermutlich hast Du einen ganz banalen Fehler in Deinen VHDL Quellen. Am besten trennst Du die Aufgabe in ihre Bestandteile auf und betrachtest jeden Teil fuer sich. Das ADC-Interface kannst Du beispielsweise testen, indem Du die eingelesenen Daten ueber eine digitale Schnittstelle ausgibst (zB ueber RS232). Das DAC Interface in aehnlicher Weise, indem Du Daten digital eingibst und mit dem Oszi schaust was rauskommt. Sobald alles fuer sich alleine funktioniert, kannst Du die Teile zusammenfuegen. Viel Erfolg, MarcArticle: 129734
Hi, I'm working with the EDK 9.2 MicroBlaze Tutorial and get the following error message: ERROR:MDT - D:\work\xilinx\HW-SPAR3E-SK-EC-G\MB_Test1\system.mhs line 245 - PARAMETER C_SPLIT has value 8 which does not fall in the range (1:C_SIZE_IN-1), specified in MPD the (hopefully relevant) section in system.mhs file are: ---8<--- ... BEGIN xps_mch_emc PARAMETER INSTANCE = FLASH PARAMETER HW_VER = 1.00.a PARAMETER C_MCH_PLB_CLK_PERIOD_PS = 10000 PARAMETER C_NUM_BANKS_MEM = 1 PARAMETER C_MAX_MEM_WIDTH = 8 PARAMETER C_MEM0_WIDTH = 8 PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1 PARAMETER C_SYNCH_MEM_0 = 0 PARAMETER C_TCEDV_PS_MEM_0 = 110000 PARAMETER C_TWC_PS_MEM_0 = 110000 PARAMETER C_TAVDV_PS_MEM_0 = 110000 PARAMETER C_TWP_PS_MEM_0 = 70000 PARAMETER C_THZCE_PS_MEM_0 = 35000 PARAMETER C_TLZWE_PS_MEM_0 = 15000 PARAMETER C_MEM0_BASEADDR = 0x89000000 PARAMETER C_MEM0_HIGHADDR = 0x89ffffff BUS_INTERFACE SPLB = mb_plb PORT Mem_A = fpga_0_FLASH_Mem_A_split PORT Mem_DQ = fpga_0_FLASH_Mem_DQ PORT Mem_OEN = fpga_0_FLASH_Mem_OEN PORT Mem_WEN = fpga_0_FLASH_Mem_WEN PORT Mem_CEN = fpga_0_FLASH_Mem_CEN END ... BEGIN util_bus_split PARAMETER INSTANCE = FLASH_util_bus_split_0 PARAMETER HW_VER = 1.00.a PARAMETER C_SIZE_IN = 32 PARAMETER C_LEFT_POS = 0 PARAMETER C_SPLIT = 8 // L245 PORT Sig = fpga_0_FLASH_Mem_A_split PORT Out2 = fpga_0_FLASH_Mem_A END ... ---8<--- what happens here? The tutorial is designed for Virtex4 / ML403 Board , but this should matter imo. I'm using the spartan3e starter kit. Thanks, OlafArticle: 129735
> what happens here? The tutorial is designed for Virtex4 / ML403 Board , > but this should matter imo. I'm using the spartan3e starter kit. ... should not matter ... sry.Article: 129736
Olaf wrote:
> BEGIN util_bus_split
> PARAMETER INSTANCE = FLASH_util_bus_split_0
> PARAMETER HW_VER = 1.00.a
> PARAMETER C_SIZE_IN = 32
> PARAMETER C_LEFT_POS = 0
> PARAMETER C_SPLIT = 8 // L245
^^
This looks like a syntax error. For comments use # and best place it on
a seperate line.
Best regards,
Andreas
Article: 129737Andreas Hofmann schrieb: > Olaf wrote: >> BEGIN util_bus_split >> PARAMETER INSTANCE = FLASH_util_bus_split_0 >> PARAMETER HW_VER = 1.00.a >> PARAMETER C_SIZE_IN = 32 >> PARAMETER C_LEFT_POS = 0 >> PARAMETER C_SPLIT = 8 // L245 > ^^ > This looks like a syntax error. For comments use # and best place it on > a seperate line. This was only for this NG to mark the line. Thanks, OlafArticle: 129738
On Mar 3, 4:08=A0am, Tricky <Trickyh...@gmail.com> wrote: > On Feb 29, 6:33 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > > > On Feb 29, 11:29 am, Tricky <Trickyh...@gmail.com> wrote: > > > > On Feb 29, 2:46 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > How to convert real to signed. The range of real will be from -1 to = 1, > > > > -5 to 5, -10 to 10 and so on. I would like to convert this range to = a > > > > signed vector of bit width bw(generic). The data has to be scaled bu= t > > > > I have no idea on how to do it. I have searched on the internet and > > > > did not find any valuable information. > > > > You will need to know magnitude width and fraction width as you will > > > be generating a fixed point decimal. > > > Magnitude width (MW) can be done by taking log2(limit) and adding 1 > > > (to account for the sign bit). > > > MW and FW of =A0output real changes with change in amplitude. What is > > 'limit'? > > > > Fraction width (FW) is then bw-MW. > > > > Then you scale the result by 2**FW and convert it to an integer (which= > > > then gives you your signed number). > > > Remember Integer(my_real) always rounds to nearest. If you dont want > > > to round to nearest, you have to write a function that rounds to zero,= > > > otherwise removing the LSBs will always round down. (towards 0 for > > > +ve, away from 0 for -ve). > > You are ignoring what the MW and FW lengths of the real are, because > it uses neither. For a real, which is floating point, its not > magnitude and fraction widths, its mantissa and exponent. You are > specified what YOU want the real to fit in to. You are making a FIXED > POINT decimal value, so MW and FW never change. for example: > > from 3 to -3 > > you need MW =3D 3 =A0(1 sign bit an 1 other bit) > FW =3D how ever many you want. each bit represets 2^-n (with n=3D0 to the > left of the imaginary point) > > so 0.75 is represended by: =A0000.1100000 =3D 2^-1 (0.5) + 2^-2 (0.25) > 1.75 =3D 001.11000000 =A0=3D 2^0 (1) + 2^-1 (0.5) + 2^-2 (0.25) > -1.75 =3D 110.01111111 (invert all bits and add one to number above) > etc > etc > All values are 2s compliment, and can then be used in any standard > adder, multiplier etc on firmware. Just make sure you use the correct > bits of the result: > > a 2.6 number x 6.2 number =3D 8.8 result > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 a a . a a a a a a > =A0 =A0 =A0 b b b b b b . b b > =3D r r r r r r r r . r r r r r r r r- Hide quoted text - > > - Show quoted text - Thanks a bunch. Your explaination really helped.Article: 129739
On Mar 4, 4:26=A0am, Tricky <Trickyh...@gmail.com> wrote: > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > I have written a process to generate random numbers using UNIFORM. I > > was trying to check the results using "rand" in matlab. How do i > > initialise the seed values of both these functions to the same value. > > I see that the random numbers generated by UNIFORM are different > > compared to rand when the seed values are left uninitialised. > > What do I need to change so that I get same output from both programs. > > > Thanks > > Uninitilised positives (the seeds in this case) will take a value of 1 > when they are put into the uniform function. Unitialised types when > used will take type'low as their value > > positive'low =3D 1 > std_logic'low =3D 'u' > etc. > > so both of your first calls to uniform are seeding it with two 1s. > > I dont know how the seeding works in matlab. It may not even use > positives, but the entire integer range. it is common in C to seed the > random number generator with the system time. Does matlab do something > similar? The C random function only has 1 seed, whereas uniform takes > 2. I am not sure how the rand function in MATLAB works. I tried to search if the code of the function was described anywhere but couldnt find. I dont know if we can get MATLAB to generate results as UNIFORM does. As you said, uniform has 2 seeds while rand has 1. If anyone has an idea on how this can be done, please post your comment.Article: 129740
On Mar 4, 2:00 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > On Mar 4, 4:26 am, Tricky <Trickyh...@gmail.com> wrote: > > > > > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > I have written a process to generate random numbers using UNIFORM. I > > > was trying to check the results using "rand" in matlab. How do i > > > initialise the seed values of both these functions to the same value. > > > I see that the random numbers generated by UNIFORM are different > > > compared to rand when the seed values are left uninitialised. > > > What do I need to change so that I get same output from both programs. > > > > Thanks > > > Uninitilised positives (the seeds in this case) will take a value of 1 > > when they are put into the uniform function. Unitialised types when > > used will take type'low as their value > > > positive'low = 1 > > std_logic'low = 'u' > > etc. > > > so both of your first calls to uniform are seeding it with two 1s. > > > I dont know how the seeding works in matlab. It may not even use > > positives, but the entire integer range. it is common in C to seed the > > random number generator with the system time. Does matlab do something > > similar? The C random function only has 1 seed, whereas uniform takes > > 2. > > I am not sure how the rand function in MATLAB works. I tried to search > if the code of the function was described anywhere but couldnt find. > I dont know if we can get MATLAB to generate results as UNIFORM does. > As you said, uniform has 2 seeds while rand has 1. > If anyone has an idea on how this can be done, please post your > comment. Why not generate a file containing all the stimulus for the vhdl and matlab model in one or the other, instead of trying to recreate the random sequence?Article: 129741
On Mar 4, 9:12=A0am, Tricky <Trickyh...@gmail.com> wrote: > On Mar 4, 2:00 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > > > On Mar 4, 4:26 am, Tricky <Trickyh...@gmail.com> wrote: > > > > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > I have written a process to generate random numbers using UNIFORM. I= > > > > was trying to check the results using "rand" in matlab. How do i > > > > initialise the seed values of both these functions to the same value= . > > > > I see that the random numbers generated by UNIFORM are different > > > > compared to rand when the seed values are left uninitialised. > > > > What do I need to change so that I get same output from both program= s. > > > > > Thanks > > > > Uninitilised positives (the seeds in this case) will take a value of 1= > > > when they are put into the uniform function. Unitialised types when > > > used will take type'low as their value > > > > positive'low =3D 1 > > > std_logic'low =3D 'u' > > > etc. > > > > so both of your first calls to uniform are seeding it with two 1s. > > > > I dont know how the seeding works in matlab. It may not even use > > > positives, but the entire integer range. it is common in C to seed the= > > > random number generator with the system time. Does matlab do something= > > > similar? The C random function only has 1 seed, whereas uniform takes > > > 2. > > > I am not sure how the rand function in MATLAB works. I tried to search > > if the code of the function was described anywhere but couldnt find. > > I dont know if we can get MATLAB to generate results as UNIFORM does. > > As you said, uniform has 2 seeds while rand has 1. > > If anyone has an idea on how this can be done, please post your > > comment. > > Why not generate a file containing all the stimulus for the vhdl and > matlab model in one or the other, instead of trying to recreate the > random sequence?- Hide quoted text - > > - Show quoted text - The goal is to check that the VHDL code generates results similar to MATLAB . I have written the outputs of both in seperate text files. I am not able to initialise the rand function to generate results similar to MATLAB and vice versa. Called MATLAB today to get some more information on how they have developed the rand function. They said that this information is not available to the public. I think one of the ways to do this would be, generating a pdf function for both cases and showing that their random distriution is similar. If any of you have other ideas please post them.Article: 129742
On Mar 4, 3:23 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > On Mar 4, 9:12 am, Tricky <Trickyh...@gmail.com> wrote: > > > > > On Mar 4, 2:00 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > On Mar 4, 4:26 am, Tricky <Trickyh...@gmail.com> wrote: > > > > > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > > I have written a process to generate random numbers using UNIFORM. I > > > > > was trying to check the results using "rand" in matlab. How do i > > > > > initialise the seed values of both these functions to the same value. > > > > > I see that the random numbers generated by UNIFORM are different > > > > > compared to rand when the seed values are left uninitialised. > > > > > What do I need to change so that I get same output from both programs. > > > > > > Thanks > > > > > Uninitilised positives (the seeds in this case) will take a value of 1 > > > > when they are put into the uniform function. Unitialised types when > > > > used will take type'low as their value > > > > > positive'low = 1 > > > > std_logic'low = 'u' > > > > etc. > > > > > so both of your first calls to uniform are seeding it with two 1s. > > > > > I dont know how the seeding works in matlab. It may not even use > > > > positives, but the entire integer range. it is common in C to seed the > > > > random number generator with the system time. Does matlab do something > > > > similar? The C random function only has 1 seed, whereas uniform takes > > > > 2. > > > > I am not sure how the rand function in MATLAB works. I tried to search > > > if the code of the function was described anywhere but couldnt find. > > > I dont know if we can get MATLAB to generate results as UNIFORM does. > > > As you said, uniform has 2 seeds while rand has 1. > > > If anyone has an idea on how this can be done, please post your > > > comment. > > > Why not generate a file containing all the stimulus for the vhdl and > > matlab model in one or the other, instead of trying to recreate the > > random sequence?- Hide quoted text - > > > - Show quoted text - > > The goal is to check that the VHDL code generates results similar to > MATLAB . I have written the outputs of both in seperate text files. I > am not able to initialise the rand function to generate results > similar to MATLAB and vice versa. Called MATLAB today to get some more > information on how they have developed the rand function. They said > that this information is not available to the public. > I think one of the ways to do this would be, generating a pdf function > for both cases and showing that their random distriution is similar. > > If any of you have other ideas please post them. In that case, why are you even trying to do this? generate a file from matlab that is used as the stimulus for the VHDL testbench. Then you do not need to use the uniform function at all, and then you are testing that the results match.Article: 129743
Hi, anybody has any (practical) information about the Common Interface specification for DVB receivers? I have some ideas (for example a DVB-CI module that feed the transport stream from DVB receiver to Ethernet) in order to analyse or broadcast to other devices in the network I have the simplest implementation would be an FPGA with an embedded CPU. Anybody knows about the Common Interface physical specification (pins,etc..) ? Any reference design or anything that can help in kick off the idea? I have seen "oficial" documentation from ETSI, CENELEC, etc. but it is too general to start quickly Thanks, ManuelArticle: 129744
Hi, anybody has any (practical) information about the Common Interface specification for DVB receivers? I have some ideas (for example a DVB-CI module that feed the transport stream from DVB receiver to Ethernet) in order to analyse or broadcast to other devices in the network I have the simplest implementation would be an FPGA with an embedded CPU. Anybody knows about the Common Interface physical specification (pins,etc..) ? Any reference design or anything that can help in kick off the idea? I have seen "oficial" documentation from ETSI, CENELEC, etc. but it is too general to start quickly Thanks, ManuelArticle: 129745
On 3 Mrz., 23:08, n...@puntnl.niks (Nico Coesel) wrote: > "M.Randelzhofer" <techsel...@gmx.de> wrote: > >"Antti" <Antti.Luk...@googlemail.com> schrieb im Newsbeitrag > >news:467475ec-6d16-4789-acec-07d3c1a4977e@s19g2000prg.googlegroups.com... > >> here it is: > > >> 1) devices densities like in Spartan-3 (50..5000) > >> 2) devices packages like Spartan-3E (including QN132 !) or better > >> (microBGA 6x6 mm?) > >> 3) all good features of S3A/AN !! > >> 4) design security with OTP encryption key (like Lattice ECP2) > >> 5) other features as already planned by Xilinx > > >> Antti > >> has made his Christmas wish this year... or did I just describe > >> Lattice XP3 or Cyclone IV? > >> eh, I just wish Spartan-4 will have all the good things from Spartan-3 > >> subfamilies+extra goodies. > > >Hi Antti, > > >I've the same wishes, some additional i/O & memory cores would be nice: > > >6) USB2 host/slave interface with integrated PHY > > >7) Ethernet MAC + PHY > > >8) DDR2/3 core > > >9) some analog stuff (ADC, temp sensor, system supervisor) > > >S4 would be a serious competitor to 32bit microcontrollers, if some of their > >standard peripherals are included in low price FPGA's. > > You forget a standard ARM core, some internal flash (say 32KB to > 256KB), some memory (8KB to 64KB) and some standard pheripherals like > UART, SPI, I2C. Such a device would be a real killer. I would design > it in straight away if it existed today for a Spartan price. > > -- > Programmeren in Almere? > E-mail naar nico@nctdevpuntnl (punt=.) well, Xilinx already own ARM IP-Core license, when Xilinx purchased Triscend they also got the IP licenses ownded by Triscend what included also ARM. so it is possible that the ARM core see new life in Spartan-4, Xilinx has no extra royalty to pay AnttiArticle: 129746
Hi. My qustion is probably dumb. But i'm stuck here. In my design I have a lot of code that can be inferred into ROM automatically, and it does. However, my device doesn't have enough ROM blocks. My question: is it possible by Quartus to infer some code into ROM blocks when it is possible and all the rest let him to make synthesis using ALUTs? Or should I manually divide all my ROM-like code to what will inferred into ROM blocks and that part which will be done usign ALUTs?Article: 129747
Hi. Oh, I forgot to write: I use Quartus 7.2sp2 and my device is EP2S60.Article: 129748
manuel-lozano@mixmail.com wrote: >anybody has any (practical) information about the Common Interface >specification for DVB receivers? >I have some ideas (for example a DVB-CI module that feed the transport >stream from DVB receiver to Ethernet) in order to analyse or broadcast >to other devices in the network >I have the simplest implementation would be an FPGA with an embedded >CPU. >Anybody knows about the Common Interface physical specification >(pins,etc..) ? Any reference design or anything that can help in kick >off the idea? The CI interface is a synchronous interface with frame & byte sync and 8-bit data. I think it's daisy chained too. It's not that complicated I think. Just search on google a bit to find.Article: 129749
"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message news:9519513d-3ee5-43cd-a73b-ee857094f8f5@e31g2000hse.googlegroups.com... > That is OK. We definitely will have jitter cleanup PLLs on the boards. Well, jitter cleanup is not what I am talking about. Take for example 10 MHz as your base clock (actually sinewave might be preferable because of better phase noise) and generate whatever your want on each of your boards with high-precision PLLs. You can even synchronize them all with a bussed signal. > I am not looking for a passive solution because I want a simple or > cheap solution, I don't know how cheap you can make it with requirements in picoseconds... /Mikhail
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