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
On Fri, 18 Sep 2009 18:26:49 GMT, phil hays <philhays@dont.spam> wrote: [snippety snip] >The size FPGA required is very hard to estimate, as there are a lot of >details needed. > >It would make sense to spend a lot of time developing the design before >choosing a part to get a good idea of the minimum cost FPGA than can do >all the required functions. Or develop on the biggest, fastest, meanest dev board that's at least several times larger, faster, etc. than a back of the envelope estimate would suggest. Place'n'route is faster, there's room for debugging hooks and sniffers, and also for the inevitable feature creep. After the dust settles and everybody signs-off on the prototype, and if the volume and cost models support it, then it may be time to squeeze the design into the cheapest silicon. If it's a low production rate item -- ten a year, not 10,000 per week -- the silicon cost may not even be a rounding error in the final unit cost and it might make sense to stay with a roomier chip. >What are the requirements? There are a lot of different application >requirements under the general category of beamforming. Some would fit in >the larger Spartan parts. Some would require more resources. Some could >be done in software only, or some combination of hardware processing and >software processing. Frequency or time domain? Adaptive, prefiltering, >noise reduction or echo cancellation per channel? Number of beams? Focus? >Shape of array? All can change the amount and type of resources required. Well, the back of a *large* envelope ... -- Rich Webb Norfolk, VAArticle: 143076
I would like to read the status register and the CRC register using HWICAP for Virtex 5 using microblaze. #include "hwicap.h" with XHwIcap_Type1Read(Register) should work. But it gives compilation error saying: "hwicap.h" is not found, and XHwIcap_Type1Read() not defined. I am using xilinx ISE 10.1 for development. How can I get the updates for these library/include files? Any help is appreciated. Thanks, buggieArticle: 143077
The idea is to find out whether fall back or current image got loaded during boot-up (as mentioned in: "Virtex-5 Configuration.pdf" chapter 6.)Article: 143078
Can you elaborate on your problem? For example, if you are looking to capture 512 signals in parallel no one FPGA is going to provide the 12,288 data lines needed to have 24 bit samples directly connected from 512 ADC chips. I would suggest using some combination of analog multiplexing and a ADC running at a much higher rate than 48KHz to capture frames of each channel then use the FPGA to demux the digital data into multiple streams. The ADCs can be synced using a master clock for parallel capturing. If you are recording samples from multiple sources, i.e. different computers on a network, you may want to drop the least significant bit and insert a time stamp that covers 8-16 samples. You can get examples of timing stamps using framing standards from most telecommunication protocols. Either means of capturing data will place a overhead on the FPGA to decode the samples and sync them. Because you are working with 512 signals the decoding/syncing overhead will not be a minor block of your design. The bandwidth would be around 73.7MB for your specification, so you will not even be able to use a USB based board to transfer the samples to/from a computer. A PCIe board would give you the band width to capture 512 signals. The key point I am making is you will not be able to find one product to fill your bill. You would be better off starting with 32 to 64 signals. If you are not flexible on the 512 signals, you may want to look at creating a capture board for capturing the signals and inserting a time stamp then use a supercluster from www.picocomputing.com to process the signals. This will break most budgets placed on academic projects, so I hope you have deep pockets. "DOD" <domenicodonisi@libero.it> wrote in message news:f2edb08f-7467-4e41-8843-6ff3d9567b8e@j9g2000vbp.googlegroups.com.. > Hi, > > i'm not an expert user of FPGA but i need to solve a problem before > starting to work on it. > I have to choose an FPGA to implement an acoustic beam forming. My > system has 512 input channels (microphones). After A/D conversion at > 48 KHz with 24 bit per sample i need to have all the 512 signals > syncronysed to perform the beamforming. So far i have read that Xilinx > tools and FPGA (Spartan or Virtex) should fix my problem but i have > difficulties in choosing the right model. > From a SW point of view I'd like to implement my model on Simulik, > translate it into VHDL and then put the code into FPGA. DO you think > that Xilinx products could solve my problem and which model do you > suggest to buy? > The FPGA + SW at about what price is sold? Please any suggestion could > be very useful for me. Thanks in advance for your help.Article: 143079
In article <9c84f43a-5edd-46ac-8a96-8d018bf626ba@f20g2000prn.googlegroups.com>, mike_la_jolla <mdini@dinigroup.com> writes: |> |> Not sure why you are using JEDEC for this. If you have the 82S153, |> just put the device on the programmer and read the fuse locations back. Uhm, yes. And which format but JEDEC do you suggest? |> What device programmer are you using? Data I/O Unisite. RainerArticle: 143080
Aio wrote: > Can you elaborate on your problem? For example, if you are looking to > capture 512 signals in parallel no one FPGA is going to provide the > 12,288 data lines needed to have 24 bit samples directly connected from > 512 ADC chips. ADC chips used for audio often have a serial interface I2S, with two channels on one serial line. That would require 256 data lines plus a word select line plus a clock, easy for a midsize or larger Spartan. http://en.wikipedia.org/wiki/I%C2%B2S -- Phil Hays (phil_hays at eeei.gro (fix the order for email)Article: 143081
You would add a lot of overhead to the design using 256 I2S interfaces. The FPGA real-estate devoted to decoding 256 I2S connections is substantial, even though you can find ready made IPCores to decode the I2S signals. Note the original question was from someone that stated they were not a expert with FPGAs, so a development board would be the best solution, but you will have to look hard for a development board with 256 accessible data lines. To create a design that would work with almost all commercial development boards, I would setup a state machine that used 24 data line input and cycles through 512 states demultiplexing the input. To make it work you would need 8 identical ADC using a two stage analog multiplexers. The output from the ADC is connected to 8to1 24bit multiplexer to connect to the FPGA. You could run the multiplexers to generate a frame of 512 24 bit samples that are synchronized. This setup will reduce the BOM size not to mention the overhead for the state machine is much less than decoding 256 I2S interfaces. The down side to the setup is the timing complexity, but everything has a trade off. example of one ADC setup analog multiplexer to ADC 16to1 -\ 16to1 -|__ 4to1--ADC ~3Msps 16to1 -| 16to1 -/ "phil hays" <philhays@dont.spam> wrote in message news:1fUsm.2691$Jd7.1421@nwrddc02.gnilink.net... > Aio wrote: > >> Can you elaborate on your problem? For example, if you are looking to >> capture 512 signals in parallel no one FPGA is going to provide the >> 12,288 data lines needed to have 24 bit samples directly connected from >> 512 ADC chips. > > ADC chips used for audio often have a serial interface I2S, with two > channels on one serial line. That would require 256 data lines plus a > word select line plus a clock, easy for a midsize or larger Spartan. > > http://en.wikipedia.org/wiki/I%C2%B2S > > > -- > Phil Hays > (phil_hays at eeei.gro (fix the order for email)Article: 143082
phil hays wrote: > Aio wrote: > >> Can you elaborate on your problem? For example, if you are looking to >> capture 512 signals in parallel no one FPGA is going to provide the >> 12,288 data lines needed to have 24 bit samples directly connected from >> 512 ADC chips. > > ADC chips used for audio often have a serial interface I2S, with two > channels on one serial line. That would require 256 data lines plus a > word select line plus a clock, easy for a midsize or larger Spartan. > > http://en.wikipedia.org/wiki/I%C2%B2S > > Texas Instruments has an 8 channel, simultaneous sampling (up to 144kHz), 24 bit serial output A/D: look up the ADS1278. Your 512 channels would require 64 devices. While the channels are sampled simultaneously they are transmitted in sequence on a single serial output. The clocks and strobes can be driven in parallel, so you'd only need 64 input pins and just a few outputs. Your 48kHz sample rate would translate into a 9.2MHz serial data rate, but that's not to difficult for an FPGA. Of course that part is $35 at DigiKey, so you'd be spending a couple thousand dollars on the A/Ds alone... Chris AbeleArticle: 143083
Actel has silently dropped all M7(ARM7 enabled) silicon. They have not announced this as big news, but true it is, there are no more M7 devices in product tables. Years ago when Actel announced M7 i wanted to get some of them, but Actel lied about the licensing, saying that there is no license fee, actual story was that the M7 silicon (what is plain FPGA + AES key) did cost maybe 100$ more then the same silicon without the key. And even so it was not possible to obtain it. So well now it is dropped for ever, no chances to get hold on it any more (unless some disti has overleft stock?). Another thing Actel did not advertize is that M7 silicon is NOT SECURE, the AES key that is programmed to the FPGA silicon is also used by Actel software tools, and hence can be easily extracted from the Actel software. This is possible, and verified, a remote site did this research for me on my request and they did deliver the "secret" M7 AES key withing 23 hours. The key was verified to really be the M7 key from Actel ARM7 enabled devices by me. So 3 FPGA companies have dropped ARM7: 1) Triscend (was killed by Xilinx) 2) Altera silicon discontinued (now offering Cortex-M3 soft-core) 3) Actel dropping M7 so the only FPGA company actually offering ARM could be xilinx with their plans for Spartan-6 extended family? AnttiArticle: 143084
On Sep 19, 5:26=A0pm, Antti <antti.luk...@googlemail.com> wrote: > Actel has silently dropped all M7(ARM7 enabled) silicon. > They have not announced this as big news, but true it is, there are no > more M7 devices in product tables. > > Years ago when Actel announced M7 i wanted to get some of them, but > Actel lied about the licensing, saying that there is no license fee, > actual story was that the M7 silicon (what is plain FPGA + AES key) > did cost maybe 100$ more then the same silicon without the key. And > even so it was not possible to obtain it. So well now it is dropped > for ever, no chances to get hold on it any more (unless some disti has > overleft stock?). An interesting move, and it suggests the License costs were exceeding the Silicon revenue ?! > Another thing Actel did not advertize is that M7 silicon is NOT > SECURE, the AES key that is programmed to the FPGA silicon is also > used by Actel software tools, and hence can be easily extracted from > the Actel software. This is possible, and verified, a remote site did > this research for me on my request and they did deliver the "secret" > M7 AES key withing 23 hours. The key was verified to really be the M7 > key from Actel ARM7 enabled devices by me. So that meant product creepage was easy? - maybe another reason to pull the plug ? > > So 3 FPGA companies have dropped ARM7: > 1) Triscend (was killed by Xilinx) > 2) Altera silicon discontinued (now offering Cortex-M3 soft-core) > 3) Actel dropping M7 You forgot Atmel's CAP series, which is probably the smartest way to add ARM. For small volumes, having ARM is unimportant, so Nios or Microblaze or Power PC is fine, for larger volumes FPGAs are too expensive/ powerhogs so Atmel's pathway is better there. > so the only FPGA company actually offering ARM could be xilinx with > their plans for Spartan-6 extended family? Plans are cheap.. ;) Cypress have plans for a Cortex with a moderate CPLD - does that count ? :) Another important point is not the core, but the memory: An ARM core in a FPGA Still needs memory, so it's only a mirage-solution, like stone-soup. Plenty of CHEAP Arm+Flash offerings out there, called Microntollers, so a designer could find a much smaller FPGA can go alongside a decent microcontroller. High Speed USB is also appearing on these devices. -jgArticle: 143085
On Sep 17, 8:28=A0am, "Niieg" <stefan.na...@kit.edu> wrote: > Hi everybody, > is it possible to generate all the names with an other name than that of > the top level entity in Alteras Quartus? > > I want it like this: > project: my_choice.qpf > top level entity: my_top.v > generated files: my_choice.rbf, my_choice.fit.rpt, my_choice.flow.rpt, > my_choice.pin, ... etc > > Quartus does this: > project: my_choice.qpf > top level entity: my_top.v > generated files: my_top.rbf, my_top.fit.rpt, my_top.flow.rpt, my_top.pin, > ... etc > > Kind regards and thank you =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.com Niieg, What matters to Quartus (in terms of naming output file names) is not the project name (.QPF file) or the top level entity name (.V/.VHD file), but the revision name (.QSF file). If you have a my_top.qsf, Quartus will generate a my_top.fit.rpt, but if you had a my_choice.qsf, it will generate a my_choice.fit.rpt. You can choose a different revision name when creating a project (at least using the New Project Wizard), or you can create/change a revision from the revision dialog box. Note that if the top level file is not equal to the revision file name, then you will be required to specify what source files you want Quartus to read, and what the top level entity is. You can do this from the "Add Files to Project" dialog. After doing that, you will see the following assignments in the QSF: set_global_assignment -name TOP_LEVEL_ENTITY "|my_top" set_global_assignment -name VERILOG_FILE my_top.v In other words, if you don't specify anything, then Quartus will assume that your project name =3D=3D revision name =3D=3D top level source file =3D=3D top level entity name, but you can change it all. - David Karchmer AlteraArticle: 143086
Hello, I'm looking under ModelSim to associate symbolic values to a vector. Example: The vector '/top_tb/state' is a 2 bit vector. I would like to associate the following values: 00 idle 01 waitSync 10 transfer 11 complete I saw a way to do this for a long time but I am not able to find it again. The way that I saw did not use VHDL. Thank you in advance for your help ThomaArticle: 143087
"Thoma" <rf.egnaro@evetsrellum> wrote in message
news:4ab4881b$0$23447$ba4acef3@news.orange.fr...
> Hello,
>
> I'm looking under ModelSim to associate symbolic values to a vector.
>
> Example:
>
> The vector '/top_tb/state' is a 2 bit vector.
> I would like to associate the following values:
> 00 idle
> 01 waitSync
> 10 transfer
> 11 complete
>
> I saw a way to do this for a long time but I am not able to find it
> again. The way that I saw did not use VHDL.
>
> Thank you in advance for your help
>
> Thoma
Look in the manual for "virtual type" and "virtual signal" commands.
This might work:
virtual type {idle waitsync transfer complete} bus_type
virtual signal {/top_tb/state} cmdbus
virtual function {(bus_type)cmdbus} command
add wave command
Hans
www.ht-lab.com
Article: 143088DOD <domenicodonisi@libero.it> wrote: > i'm not an expert user of FPGA but i need to solve a problem before > starting to work on it. I suggest a systolic array. Without knowing what computation you want to perform it is hard to say, but systolic arrays work for a variety of such processing problems. -- glenArticle: 143089
Aio wrote: > You would add a lot of overhead to the design using 256 I2S interfaces. Compared to what total design size? They might be using digital microphones which already output I2S or similar digital serial standards, or may be planning on using a microphone array with integrated ADCs. In which case, they will need to implement I2S or similar interfaces somewhere. An I2S input is a shift register the size of the data, and a counter log 2 of the data size to keep track of word boundaries, and a few extra FFs for handshaking. In V6/S6, that would be 3 slices for the data (24 FFs), 2 slices for the counter, and perhaps another slice for handshaking. As the counter bits and handshaking can be shared between channels, we really only need ~3 slices per channel. With 4 slices per channel, 4*256 slices is 10% of a XC6SLX75. A ready made IP core probably isn't close to minimal sized (3X or more?), so you do have a point. But until the size of the design is known better, which will require doing some Matlab development and seeing how large the resulting implementation is, it is hard to guess if the size of the I2S interfaces would be significant. > The FPGA real-estate devoted to decoding 256 I2S connections is > substantial, even though you can find ready made IPCores to decode the > I2S signals. Note the original question was from someone that stated > they were not a expert with FPGAs, so a development board would be the > best solution, but you will have to look hard for a development board > with 256 accessible data lines. This is overkill, most probably, but no problem finding one. http://www.synplicity.com/literature/haps/datasheets/haps-54-ds.pdf 2856 IOs is probably a few more than required. Probably enough slices to make 256 I2S interfaces look pretty trivial in size as well. > To create a design that would work with almost all commercial > development boards, I would setup a state machine that used 24 data line > input and cycles through 512 states demultiplexing the input. To make it > work you would need 8 identical ADC using a two stage analog > multiplexers. The output from the ADC is connected to 8to1 24bit > multiplexer to connect to the FPGA. You could run the multiplexers to > generate a frame of 512 24 bit samples that are synchronized. This > setup will reduce the BOM size not to mention the overhead for the state > machine is much less than decoding 256 I2S interfaces. The down side to > the setup is the timing complexity, but everything has a trade off. On TI's website I see that a 4 Msps ADC has a SNR of 93 db, and a 144 Ksps ADC has a SNR of 111 dB. Is 18 dB of SNR important? Can't say, don't know enough about the application. And the analog multiplexer doesn't make the 4 Msps DAC look any better. Tradeoffs are everywhere. -- Phil Hays (phil_hays at eeei.gro (fix the order for email)Article: 143090
On Sep 19, 9:02=A0am, malcolm <malcolm...@gmail.com> wrote: > On Sep 19, 5:26=A0pm, Antti <antti.luk...@googlemail.com> wrote: > > > Actel has silently dropped all M7(ARM7 enabled) silicon. > > They have not announced this as big news, but true it is, there are no > > more M7 devices in product tables. > > > Years ago when Actel announced M7 i wanted to get some of them, but > > Actel lied about the licensing, saying that there is no license fee, > > actual story was that the M7 silicon (what is plain FPGA + AES key) > > did cost maybe 100$ more then the same silicon without the key. And > > even so it was not possible to obtain it. So well now it is dropped > > for ever, no chances to get hold on it any more (unless some disti has > > overleft stock?). > > =A0An interesting move, and it suggests the License costs were exceeding > the Silicon revenue ?! > > > Another thing Actel did not advertize is that M7 silicon is NOT > > SECURE, the AES key that is programmed to the FPGA silicon is also > > used by Actel software tools, and hence can be easily extracted from > > the Actel software. This is possible, and verified, a remote site did > > this research for me on my request and they did deliver the "secret" > > M7 AES key withing 23 hours. The key was verified to really be the M7 > > key from Actel ARM7 enabled devices by me. > > So that meant product creepage was easy? - maybe another reason to > pull the plug ? > > > > > So 3 FPGA companies have dropped ARM7: > > 1) Triscend (was killed by Xilinx) > > 2) Altera silicon discontinued (now offering Cortex-M3 soft-core) > > 3) Actel dropping M7 > > You forgot Atmel's CAP series, which is probably the smartest way to > add ARM. For small volumes, having ARM is unimportant, so Nios or > Microblaze no i did not, its structured ASIC, not FPGA so it does NOT count > or Power PC is fine, for larger volumes FPGAs are too expensive/ > powerhogs so Atmel's pathway is better there. PowerPC is dead no longer offered in V-6 so its dead end path already > > > so the only FPGA company actually offering ARM could be xilinx with > > their plans for Spartan-6 extended family? > > =A0Plans are cheap.. ;) > > =A0Cypress have plans for a Cortex with a moderate CPLD - does that > count ? :) > no, its Cortex-M3 not ARM7 > =A0Another important point is not the core, but the memory: An ARM core > in a FPGA Still needs memory, so it's only a mirage-solution, like > stone-soup. > > Plenty of CHEAP Arm+Flash offerings out there, called Microntollers, > so a designer could find a much smaller FPGA can go alongside a decent > microcontroller. > High Speed USB is also appearing on these devices. > > -jg where can i find info about "Microntollers" ? is it something like transputers or XMOS? and who are you, you signed as -jg what would be Jim Granville, but your account says Malcolm? Antti Lukats aka Antti LukatsArticle: 143091
On Sep 20, 12:34=A0am, "Antti.Luk...@googlemail.com" <antti.luk...@googlemail.com> wrote: > and who are you, you signed as > -jg > > what would be Jim Granville, but your account says Malcolm? oops, yes Antti, - did not spot that my son had re-logged in... -jgArticle: 143092
On Sep 20, 12:34=A0am, "Antti.Luk...@googlemail.com" <antti.luk...@googlemail.com> wrote: > > =A0Cypress have plans for a Cortex with a moderate CPLD - does that > > count ? :) > > no, its Cortex-M3 not ARM7 Oh, If you are making that distinction, then ARM7 is close to NFND. So no surprise there. Cortex M3 and Cortex M0 will be the alternative FPGA-cores, on that pathway. -jgArticle: 143093
On Sep 15, 4:01=A0am, "Antti.Luk...@googlemail.com" <antti.luk...@googlemail.com> wrote: > On Sep 15, 10:26=A0am, luudee <rudolf.usselm...@gmail.com> wrote: > > > > > On Sep 13, 6:08=A0pm, "Antti.Luk...@googlemail.com" > > > <antti.luk...@googlemail.com> wrote: > > > > the place is right > > > > just that the models are of no good in many cases > > > > Antti > > > I disagree with you Antti. I have used numerous times and > > it works just fine. > > > For an open project (e.g. OpenCores) to succeed, it would > > be great if you would contribute to the project and fix > > whatever you think is broken. Actually, since it is gone > > all together now, why not create a universal memory model ? > > I know you are very knowledgeable with almost every vendors > > tools ... > > > Cheers, > > rudi > > :) > > YES > OF COURSE they have been used in many projects with success. > it doesnt mean they can always be used for all vendors in all usage > scenarious. > > yes, i work 5 vendors at the moment, but well it really to my > knowledge > is not possible to create models that use all different features of > the > block ram primitives for all 5 vendors > > of course i would be nice to have generic models that do it all > for all vendors and all synthesis tools, > but as of today it isnt possible > > Antti You certainly *can* write a universal model that will provide all the features of all vendors block ram primitives, at least the features that you *can* utilize from generic code at all. If nothing else, the vendor can be specified and generate statements used to select which code to implement. I actually have done this when using vendor's instantiation code. I use generate statements to allow changing the target between brands and families. I never filled it out as I only added code for the parts I needed at the time. I'm not suggesting that the "generic" models instantiate primitives. I am suggesting that for specific features of different vendors may require generate statements to infer them without creating compatibility problems. RickArticle: 143094
On Mon, 7 Sep 2009 16:13:14 +0800, Hendrik wrote (in article <356f8c44-9167-4bcc-9d88-79dabefc9cd4@l13g2000yqb.googlegroups.com>): > Today, Sigasi proudly announces Mac OS X support for Sigasi HDT, an > Intelligent Development Environment (IDE) for VHDL. > > Sigasi HDT is built upon the widely accepted Eclipse platform and > contains an ultra-fast VHDL parser and compiler. As a result, the tool > fully understands a design in terms of VHDL concepts. > > The tool is currently available in a public beta program. From user > feedback, we learned that there is a significant interest in Mac OS X > support. > > Sigasi HDT for Mac OS X is immediately available for download, please > visit http://www.sigasi.com/start. Another shitty java implementation IDE under eclipseArticle: 143095
On Sep 18, 3:25=A0pm, buc...@atbode100.lrr.in.tum.de (Rainer Buchty) wrote: > In article <9c84f43a-5edd-46ac-8a96-8d018bf62...@f20g2000prn.googlegroups= .com>,=A0mike_la_jolla <md...@dinigroup.com> writes: > > |> > |> Not sure why you are using JEDEC for this. =A0If you have the 82S153, > |> just put the device on the programmer and read the fuse locations back= . > > Uhm, yes. And which format but JEDEC do you suggest? > > |> What device programmer are you using? > > Data I/O Unisite. > > Rainer Flip thru the menus. I remember being able to get a hex number the represented the fuses blown on each row. With that info, you can extract the equations from the fuse map in the datasheet. You can get this info from the JEDEC. I think the JEDEC gives fuse numbers '0- >whatever' in hex format. With the JEDEC file, you would need to know how the fuses are numbered. You will still need to go back to the fuse map to get the equations.Article: 143096
On Sep 20, 12:31=A0am, -jg <jim.granvi...@gmail.com> wrote: > On Sep 20, 12:34=A0am, "Antti.Luk...@googlemail.com"<antti.luk...@googlem= ail.com> wrote: > > > =A0Cypress have plans for a Cortex with a moderate CPLD - does that > > > count ? :) > > > no, its Cortex-M3 not ARM7 > > Oh, If you are making that distinction, then ARM7 is close to NFND. > > So no surprise there. > Cortex M3 and Cortex M0 will be the alternative FPGA-cores, on that > pathway. > > -jg actually M1 only I think M0 is ASIC only, it would be larger than M1 M3 is much larger then M1 so as of soft core only M1 is feasible, not M0 I have compiled M3 and M1 RTL for different FPGA and M1 is small :) as of ARM7 close to NFND, you right I didnt think of that loud, but i guess it was in my mind too AnttiArticle: 143097
HT-Lab a écrit :
>> I'm looking under ModelSim to associate symbolic values to a vector.
>>
>> Example:
>>
>> The vector '/top_tb/state' is a 2 bit vector.
>> I would like to associate the following values:
>> 00 idle
>> 01 waitSync
>> 10 transfer
>> 11 complete
>>
>> I saw a way to do this for a long time but I am not able to find it
>> again. The way that I saw did not use VHDL.
>
> Look in the manual for "virtual type" and "virtual signal" commands.
>
> This might work:
>
> virtual type {idle waitsync transfer complete} bus_type
> virtual signal {/top_tb/state} cmdbus
> virtual function {(bus_type)cmdbus} command
> add wave command
>
> Hans
> www.ht-lab.com
>
>
Hi Hans,
It is exactly what I search for.
Thank you for your help
Thoma
Article: 143098In article <d9ac727d-4500-4b34-a887-f88d442bb53c@13g2000prl.googlegroups.com>, mike_la_jolla <mdini@dinigroup.com> writes: |> |> Flip thru the menus. I remember being able to get a hex number the |> represented the fuses blown on each row. JEDEC (Unisite formats 91/92) is just fine. Gives line numbers and fusemap, although as a longer chunk than the average software seems to like to digest. Interestingly, when I use a hex dump format I get extra information at the beginning I don't see in the JEDEC file, e.g. 000000EF 000000EF trailing the pterm fusemap. Anyone knows whether this is some device ID or the check fuses mentioned in the data sheet? |> With that info, you can |> extract the equations from the fuse map in the datasheet. Well, the trickery part was that there's no fuse map in the data sheet. But, then, it wasn't too hard to figure out what the product terms, sum terms, and control terms were. Strangely enough, there seem to be two methods of filling a PLS153, one is from fuse 0 on, the other from use 644 on. In the first case, the unused block is zero-ed, in the second case it's one-d. From the generated JEDEC files, I didn't find any other means of differentiation. RainerArticle: 143099
On Mon, 14 Sep 2009 17:28:28 -0500, "ravisguptaji" <rsgupta.gupta@gmail.com> wrote: >Hi All, >I have to get all this done in a single clk cycle in verilog. >Requirement for Synthesis: >Y = (INT(A/(B*C))) * (B*C); >Where, >A is a fixed 32 bit value; >B is 2**X, X is a 3 bit value, hence B varies from 2 pow 0 to 2 pow 7; >C is len + 1, len is a 4 bit value, and valid len is : 2,4,8 and 16; I don't think you quite wrote that correctly. If 'len' is a 4-bit value, it can't be 16. I would guess that the values 2,4,8,16 are the valid values for C, not for 'len', and that len will be 1/3/7/15. If that's true, then it is very easy indeed, since it is only necessary to build a bit-mask and then AND it with the original input value. And the bit-mask is simply ~C, left-shifted by X bit positions. That sounds like Y = A & ((~C) << X); which also appears to be functionally the same as the code example you gave. Note that ~C will automatically be widened to 32 bits by Verilog's bit-widening rules, so you'll get the correct set of 1 bits on the left. Try it in synthesis, compare it with your version. Synthesis does pretty good optimization of this kind of logic, so it may not make any difference. -- 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.
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