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
Well it's not new at all, but I've just discovered Yet Another Open Source RISC core -- Lattice's Mico32. It comes with GNU tool-chain (making the software-development side similar to OpenRisc 1200?) and even has a built-in debug-module. How popular these Opensource cores really are? I know the Opencores EMAC 10/100 gets a lot of use in commercial ASIC projects. But the CPU-cores rarely get the same attention (mostly just academic or government-funded stuff.) Could someone explain why? Is it their performance (IPC, area, power-consumption)? Is it lack of a supported embedded O/S port?Article: 121651
hi all, how to convert integer numbers to real numbers and vice-vers. and what will be the hardware generated for real multiplication. please reply soon ... thanksArticle: 121652
On 7 8 , 1 16 , "water9...@yahoo.com" <water9...@yahoo.com> wrote:
> On 7 8 , 12 49 , "water9...@yahoo.com" <water9...@yahoo.com> wrote:
>
> > I use Xilinx PCSPMA GTP IP core to connect ML555 SFP interface. But
> > how to connect the signal_detect signal of PCSPMA GTP core to indicate
> > presence of optical input?
>
> SFP{1/2}_LOS is connected LED of ML555,no FPGA Pin.
>
> how to connect the signal_detect signal of PCSPMA GTP core ?
no helps?
Article: 121653Xilinx User wrote: > Well it's not new at all, but I've just discovered Yet Another Open Source > RISC core -- Lattice's Mico32. It comes with GNU tool-chain (making the > software-development side similar to OpenRisc 1200?) and even has a > built-in debug-module. > > How popular these Opensource cores really are? I know the Opencores EMAC > 10/100 gets a lot of use in commercial ASIC projects. But the CPU-cores > rarely get the same attention (mostly just academic or government-funded > stuff.) Could someone explain why? > > Is it their performance (IPC, area, power-consumption)? Is it lack of a > supported embedded O/S port? What's your question exactly - why FPGA cores are not seen more in ASICS ? - I get the impression Leon is doing quite well, in its niche. Mico32 is very new, and is really the first open source FPGA-centric core, so I'd expect it will show up in ASICs. Would you count a NIOS II licensed for ASIC use, either via the Altera flow, or in a full asic. Of course, ASIC design starts are a tiny fraction of fpgA design starts, so any core usage in that direction has to be small. -jgArticle: 121654
"ujjwal" <rakeshujjawal@gmail.com> wrote in message
news:1184133651.719268.225050@e16g2000pri.googlegroups.com...
> hi all,
>
> how to convert integer numbers to real numbers and vice-vers. and what
> will be the hardware generated for real multiplication.
>
> please reply soon ...
>
> thanks
>
Did you bother to Google? I guess not...
Q1.
vhdl convert integer real
Q2.
fpga multiplier structure site:xilinx.com
fpga multiplier structure site:altera.com
HTH, Syms.
Article: 121655"Ace" <yasirmm@gmail.com> wrote in message news:1184120672.818278.40070@57g2000hsv.googlegroups.com... > Hi, > > I was told by a friend that SystemC is currently the best to modeling > hw/sw design. I've read on the internet where people were saying that > SystemC is a more "complete model" which I don't quite understand. > I've look at several other tools for example Impulse C that gave a > very good description on how hw/sw modeling can be done easily using > Impulse C. > > Could anyone be kind to share why do you think systemC is the best > tool to model hw/sw and how? I'm open to any good source should you > wish to share. It is difficult to say if SystemC is the best language for hw/sw modelling since there are a number of other good languages competing in that space for which I personally have no knowledge. However, what I do know is that SystemC is quite a powerful language (more accurately a C++ class library and event based simulator). You can use all the power of C++ and at the same time use the SystemC class library to model concurrency (e.g. you can model with and without delta cycles). However, were the language is not so good (I was told) is in supporting gate-level models but then again it wasn't developed for that purpose. You might also want to look at SystemVerilog which overlaps with SystemC to a certain degree. In general one can say that SystemVerilog allows you to go lower, that is, towards gate-level whereas SystemC allows you to go higher towards Operating Systems. You will get a much better answer if you post this question to the SystemC newsgroup at www.systemc.org :-) Hans www.ht-lab.com > > > Cheers! >Article: 121656
On 11 Jul, 05:29, "Xilinx User" <anonym...@net.com> wrote: > Well it's not new at all, but I've just discovered Yet Another Open Source > RISC core -- Lattice's Mico32. It comes with GNU tool-chain (making the > software-development side similar to OpenRisc 1200?) and even has a > built-in debug-module. > > How popular these Opensource cores really are? I know the Opencores EMAC > 10/100 gets a lot of use in commercial ASIC projects. But the CPU-cores > rarely get the same attention (mostly just academic or government-funded > stuff.) Could someone explain why? Risk. Spending a couple of hundred k on a CPU with commercial support is not that big a deal if you're making ASICs. > Is it their performance (IPC, area, power-consumption)? Performance should be pretty comparible to the low-end commerical offerings. Something like Mico32 is very much stripped down to minimize LUT count, so some of the bells ans whistles you'll find in dedicate ASIC CPUs are missing. Cheers, JonArticle: 121657
> Performance should be pretty comparible to the low-end commerical > offerings. Something like Mico32 is very much stripped down to > minimize LUT count, so some of the bells ans whistles you'll find in > dedicate ASIC CPUs are missing. Of course the flip side is when you try to prototype an ASIC CPU in an FPGA. Laughable performance. Cheers, JonArticle: 121658
Thank you for the reply however I did what was suggested - In the System
Generator Block I have the sample period set to 1/80e6 where I defined
SystemClk as 80e6, and for the filter I have it set to (1/100e3) = 10e-6 =
800/SystemClk. When I view the sample rates in the model I see 800 for the
inputs to the filter and 400 for the outputs. This seems ok to me. I do get
a message window stating that the simulink period is too small for the rates
used in the model and that a better value would be 1/100e3.
When I run the simulation I never get past the 0ps point and I get the
error stating Boolean type output port op gets indeterminate value but it
doesn't specify which block actually caused it. The message states the
default block is the source? A second error states Error reported by
S-function "sysgen" in filt/BlackBox. Summary of errors from all sources.
None of the errors was associated with a particular block; the block
reported was chosen at random?
If I redefine SystemClk to 1e6 then the simulation will run but
certainly won't match the real VHDL simulation.
Yesterday by editing the config.m file for the filter I eventually got
the model to run for 5 microseconds using the 80MHz clk. There are 3 clks
showing up in Modelsim, the 80MHz, a 200KHz (400*(1/TSystemclk), and a
100KHz.(800*(1/TSystemClk) but it looked like at the first transition of
the 200KHz clock that the same indeterminate Boolean value error occurred!.
In Modelsim the top level module is named filter_cosim_cw. It shows the
clk_400_sg_x0 and clk_800_sg_x0 as 'U' while the underlying module for the
filter shows a value of '1' for these clks when the simulation stops. Is
there anyway to have the sim ignore this error and continue? The only
Booleans I use are the output of comparators on the seli and selo lines of
the multichannel filter. Should I not use them and compare bits in logic
instead? Any ideas would be appreciated.
BTW, the filter I'm modeling was used a few years back, so at this point
I don't want to change it using the FIR compiler. Is the FIR compiler a
Matlab thing or is it in the Core Generator?
CTW
<naude.jaco@gmail.com> wrote in message
news:1183988465.125745.23520@k79g2000hse.googlegroups.com...
> On Jul 8, 4:08 am, "cwoodring" <cwoodr...@cox.net> wrote:
>> Hi,
>> I've been working on a simulink model built using the Xilinx Blockset
>> to
>> try to verify the function of an interpolation filter made from the
>> MacFir
>> Core. The full working VHDL version of the complete data path where the
>> input data goes into a FIFO and is read out to the filter as it is ready
>> for
>> data. The filter does a simple up by 2 interpolation and the output data
>> is
>> written to another FIFO for eventual output. This filter actually handles
>> 64
>> channels. The input rate for the data is 100KHz and the Output rate is to
>> be
>> 200KHz.
>> In my simulink model I read the data for a input signal consisting of
>> 2
>> sine waves, one well within the filters passband and one in the stop
>> band,
>> from the MATLAB workspace. I then multiplex that same data to 28 channels
>> and feed the filter which is instantiated in the Simulink model as a
>> black
>> box as per Matlab's help file for inserting a Xilinx core into a model.
>> I've had a lot of confusion about sample rates and how to deal with
>> them
>> in Simulink, but I think I'm finally getting the hang of them. The output
>> rate is 2x the input rate for the complete system - FIFO in to FIFO out
>> but
>> the filter runs very fast compared to the actual data rate in and out.
>> The Modelsim simulation of the whole VHDL coded system seems to be
>> working- I get 2 samples out for every one in on all the channels and the
>> data is written to the output fifos ok. Since the data is fixed point I
>> wanted to verify my output values with what I get in the Simulink model
>> which uses the fixed point blockset etc. The biggest issue I have is
>> that
>> the Modelsim simulation goes very fast and outputs data from the filter
>> every usec or less while the Simulink model using the Modelsim output
>> block
>> takes milliseconds to produce an output data. It does give me 2 values
>> for
>> every one in and the filter model appears to be working ok, but the
>> clocking
>> of the whole model is running at a sample rate of 100KHz. . I use
>> modelsim
>> under the control of Simulink to run the simulation and the fastest clock
>> in
>> the simulation is 200KHz. The system clock in the "real" VHDL system is
>> 80MHz. When I try to increase the system clock in the SystemGenerator
>> block
>> to anything faster than 1MHz I get some error about an unresolved Boolean
>> value and the simulation doesn't run.
>> Has anyone matched what an actual synthesizable system to a Simulink
>> model at the actual clock rates used in the VHDL simulation? When I look
>> at
>> all the example files for simulink it seems they always use sample rates
>> of
>> 1sec which seems ridiculous when trying to match clock rates in an FPGA
>> system. Am I really off the mark here or to I just have to run my
>> Simulink
>> model for 45 minutes to match what the VHDL model gives me in 2 seconds?
>>
>> Totally dazed and confused,
>>
>> CTW
>
> There are different ways to handle the clocks in System Generator. It
> can be confusing.
>
> If your real clock is going to be 80MHz, create a variable
> T_system_clock = 1/80e6 in your Matlab workspace. Use this variable in
> your System Generator token. Now make sure that the clock rates in
> your system are all integer multiples of this clock. For example, if
> your FIR input runs at 100kHz, set the sample period of the filter =
> (1/100e3)/T_system_clock. This will be an integer multiple of the
> system clock. Now in the Simulink 'Simulation Stop Time' you put
> N*T_system_clock where N is the number of clock cycles which you want
> to run the simulation for. The times shown in a scope window for
> example will match the actual time related to the 80MHz clock in
> hardware.
>
> Basically the clock that is specified in the System Generator token
> must be equal to the fastest clock in your system, the slower clocks
> will all be generated with CE's by System Generator and you will not
> get errors about clocks that are not integer clock cycles of the
> system clock.
>
> One more thing, use the FIR Compiler and not the MAC FIR as it will be
> replaced by the FIR Compiler.
>
> Hope this helps
>
Article: 121659On Jul 10, 6:39 pm, "Symon" <symon_bre...@hotmail.com> wrote: > "John_H" <newsgr...@johnhandwork.com> wrote in message > > news:1397vp67lj8hoeb@corp.supernews.com...> "Naveen" <vnaveen2...@gmail.com> wrote in message > >news:1184098009.564479.140190@o11g2000prd.googlegroups.com... > >>I am using ISE 9.1i. I am getting an error in the Map process which > >> says " Process MAP Fail" without showing any errors. There happens to > >> be bug which was solved in 8.2i Service Pack 1, but still I am facing > >> this bug. > >> Does anyone know how to fix this? > > >> Thanks in advance. > >> Naveen > > > Do any of your file names or directory paths used have spaces in their > > names? If so, move to where the are no spaces. As silly and annoying as > > this sounds, it's still showing up in too much EDA software. > > Hence.. John_H ! :-) [rant on] Spaces in folder (directory) names has been a sore point with me since introduced to Windows NT. I fail to see the advantage of this in general, and it is cumbersome when dealing with any programs at a command line level. All of this would be O.K. if we weren't *forced* to use spaces by the standard installation names in Windows (at least the English language version) like "Program Files" and my least favorite "Documents and Settings". So if you need to type commands and hate quoting everything, forget installing programs in the standard place and forget placing any items on your desktop or "My Documents". That the work-arounds to this annoyance are still missing in a lot of EDA software just points to the fact that much of this software was not developed on Windows in the first place. [rant off] Cheers, GaborArticle: 121660
water9580@yahoo.com wrote: >> how to connect the signal_detect signal of PCSPMA GTP core ? pg202 http://www.xilinx.com/ipcenter/1gbsx_phy_lounge/gig_eth_pcs_pma_ug155.pdfArticle: 121661
> Well it's not new at all, but I've just discovered Yet Another Open Source > RISC core -- Lattice's Mico32. It comes with GNU tool-chain (making the > software-development side similar to OpenRisc 1200?) and even has a > built-in debug-module. I've also noticed the lm32. It is really well documented. My only objection (but hopefully this will change, i think it is under consideration) is that Lattice provides only Verilog sources (which is the language of preference for me). A quick sum-up would include: PicoBlaze, MicroBlaze, Nios-II, LatticeMico32, LEON2/3, OpenRISC. It would also be proper to add here some bytecode interpreter engines (most notably JOP), but they are not intended for general-purpose apps. All the above are 32-bit machines except PicoBlaze. I have added PicoBlaze in the list, because i find it really useful and a very powerful processor for control-oriented applications. It has predictable real-time performance and a large number (up to 256) of i/ o ports. I have recently set up a couple of lab exercises (one with PicoBlaze solo and a second one with a RISC core of mine and a PicoBlaze) and i'm very positive over PicoBlaze. > How popular these Opensource cores really are? I know the Opencores EMAC > 10/100 gets a lot of use in commercial ASIC projects. But the CPU-cores > rarely get the same attention (mostly just academic or government-funded > stuff.) Could someone explain why? It is strange but all the above RISC cores have good toolchains so someone would expect a wider adoption (adoption is good for the vertical markets they are intended to for the time being). The positive thing here is that there is no way but up. Embedded processing and FPGAs will grow as CLB counts will rise and power consumption (hopefully) will drop). > Is it their performance (IPC, area, power-consumption)? Is it lack of a > supported embedded O/S port? And most of the 32-bit cores have at least some kind of support for embedded OSes (RTEMS, uClinux and others even commercial ones like uCOS series). But finally i donnot understand if there is a question posed here. Do you have to choose between a open core and a closed-source solution. Or are you between using a programmable processor core and using something more customized for your case? Nikolaos KavvadiasArticle: 121662
Are you guaranteed a constant phase relationship between you sampler and samplee signals? If not, then it doesn't directly matter what the setup time is (I think I remember Peter saying that they have zero hold time), because the sampled signal is completely asyncronous to the sampling clock and will eventually violate the setup time of the flop, even if its pulses were a day long. ---Matthew Hicks > Hi, > > For our VHDL design, we are using an evaluation board that has a > Xilinx > Virtex-II Pro chip on it. The design calls for sampling of a digital > signal at 100MHZ. The problem is that the signal contains very short > pulses, given at random intervals. > It's therefore necessary to make sure that the sampler (which is > implemented by the flip-flop found in the CLB) can register these > pulses, > or at least to have an idea of which ones it can register. > So the question is, what is the setup and hold time constraints of > those flip-flops? I looked in the datasheet, but couldn't find these > figures. The clock to ouput times and so forth were listed, but not > this specific setup time. The timing analyzer also didn't give me a > satisfying result. > > Thanks a lot for your reply, > Berk BirandArticle: 121663
> A quick sum-up would include: MicroBlaze, Nios-II, Since when were these open source? Cheers, JonArticle: 121664
You can't easily multiply real numbers in HDL code. You could use an IP core for it, or you could represent the numbers in a fixed point format and multiply them. ---Matthew Hicks > hi all, > > how to convert integer numbers to real numbers and vice-vers. and what > will be the hardware generated for real multiplication. > > please reply soon ... > > thanks >Article: 121665
On Jul 11, 1:17 pm, "cwoodring" <cwoodr...@cox.net> wrote: > Thank you for the reply however I did what was suggested - In the System > Generator Block I have the sample period set to 1/80e6 where I defined > SystemClk as 80e6, and for the filter I have it set to (1/100e3) = 10e-6 = > 800/SystemClk. When I view the sample rates in the model I see 800 for the > inputs to the filter and 400 for the outputs. This seems ok to me. I do get > a message window stating that the simulink period is too small for the rates > used in the model and that a better value would be 1/100e3. > When I run the simulation I never get past the 0ps point and I get the > error stating Boolean type output port op gets indeterminate value but it > doesn't specify which block actually caused it. The message states the > default block is the source? A second error states Error reported by > S-function "sysgen" in filt/BlackBox. Summary of errors from all sources. > None of the errors was associated with a particular block; the block > reported was chosen at random? > If I redefine SystemClk to 1e6 then the simulation will run but > certainly won't match the real VHDL simulation. > Yesterday by editing the config.m file for the filter I eventually got > the model to run for 5 microseconds using the 80MHz clk. There are 3 clks > showing up in Modelsim, the 80MHz, a 200KHz (400*(1/TSystemclk), and a > 100KHz.(800*(1/TSystemClk) but it looked like at the first transition of > the 200KHz clock that the same indeterminate Boolean value error occurred!. > In Modelsim the top level module is named filter_cosim_cw. It shows the > clk_400_sg_x0 and clk_800_sg_x0 as 'U' while the underlying module for the > filter shows a value of '1' for these clks when the simulation stops. Is > there anyway to have the sim ignore this error and continue? The only > Booleans I use are the output of comparators on the seli and selo lines of > the multichannel filter. Should I not use them and compare bits in logic > instead? Any ideas would be appreciated. > BTW, the filter I'm modeling was used a few years back, so at this point > I don't want to change it using the FIR compiler. Is the FIR compiler a > Matlab thing or is it in the Core Generator? > > CTW<naude.j...@gmail.com> wrote in message > > news:1183988465.125745.23520@k79g2000hse.googlegroups.com... > > > On Jul 8, 4:08 am, "cwoodring" <cwoodr...@cox.net> wrote: > >> Hi, > >> I've been working on a simulink model built using the Xilinx Blockset > >> to > >> try to verify the function of an interpolation filter made from the > >> MacFir > >> Core. The full working VHDL version of the complete data path where the > >> input data goes into a FIFO and is read out to the filter as it is ready > >> for > >> data. The filter does a simple up by 2 interpolation and the output data > >> is > >> written to another FIFO for eventual output. This filter actually handles > >> 64 > >> channels. The input rate for the data is 100KHz and the Output rate is to > >> be > >> 200KHz. > >> In my simulink model I read the data for a input signal consisting of > >> 2 > >> sine waves, one well within the filters passband and one in the stop > >> band, > >> from the MATLAB workspace. I then multiplex that same data to 28 channels > >> and feed the filter which is instantiated in the Simulink model as a > >> black > >> box as per Matlab's help file for inserting a Xilinx core into a model. > >> I've had a lot of confusion about sample rates and how to deal with > >> them > >> in Simulink, but I think I'm finally getting the hang of them. The output > >> rate is 2x the input rate for the complete system - FIFO in to FIFO out > >> but > >> the filter runs very fast compared to the actual data rate in and out. > >> The Modelsim simulation of the whole VHDL coded system seems to be > >> working- I get 2 samples out for every one in on all the channels and the > >> data is written to the output fifos ok. Since the data is fixed point I > >> wanted to verify my output values with what I get in the Simulink model > >> which uses the fixed point blockset etc. The biggest issue I have is > >> that > >> the Modelsim simulation goes very fast and outputs data from the filter > >> every usec or less while the Simulink model using the Modelsim output > >> block > >> takes milliseconds to produce an output data. It does give me 2 values > >> for > >> every one in and the filter model appears to be working ok, but the > >> clocking > >> of the whole model is running at a sample rate of 100KHz. . I use > >> modelsim > >> under the control of Simulink to run the simulation and the fastest clock > >> in > >> the simulation is 200KHz. The system clock in the "real" VHDL system is > >> 80MHz. When I try to increase the system clock in the SystemGenerator > >> block > >> to anything faster than 1MHz I get some error about an unresolved Boolean > >> value and the simulation doesn't run. > >> Has anyone matched what an actual synthesizable system to a Simulink > >> model at the actual clock rates used in the VHDL simulation? When I look > >> at > >> all the example files for simulink it seems they always use sample rates > >> of > >> 1sec which seems ridiculous when trying to match clock rates in an FPGA > >> system. Am I really off the mark here or to I just have to run my > >> Simulink > >> model for 45 minutes to match what the VHDL model gives me in 2 seconds? > > >> Totally dazed and confused, > > >> CTW > > > There are different ways to handle the clocks in System Generator. It > > can be confusing. > > > If your real clock is going to be 80MHz, create a variable > > T_system_clock = 1/80e6 in your Matlab workspace. Use this variable in > > your System Generator token. Now make sure that the clock rates in > > your system are all integer multiples of this clock. For example, if > > your FIR input runs at 100kHz, set the sample period of the filter = > > (1/100e3)/T_system_clock. This will be an integer multiple of the > > system clock. Now in the Simulink 'Simulation Stop Time' you put > > N*T_system_clock where N is the number of clock cycles which you want > > to run the simulation for. The times shown in a scope window for > > example will match the actual time related to the 80MHz clock in > > hardware. > > > Basically the clock that is specified in the System Generator token > > must be equal to the fastest clock in your system, the slower clocks > > will all be generated with CE's by System Generator and you will not > > get errors about clocks that are not integer clock cycles of the > > system clock. > > > One more thing, use the FIR Compiler and not the MAC FIR as it will be > > replaced by the FIR Compiler. > > > Hope this helps Hi, The message window stating that the simulink period is too small for the rates used in the model and that a better value would be 1/100e3 sounds normal if you don't have anything running at the 80MHz frequency. Simulink will notice this and let you know that a better setting would be the fastest rate used in your design. Thus the filter rate. Using the 80MHz clock frequency as the sample period in your SysGen token might not be the best option if you don't have anything running at that frequency as this will increase the simulation times in Simulink quite significantly. It depends if you want it to match your VHDL simulation or not. What I normally do is I take the fastest frequency in my design. When looking at the spectrum of any signal in my design I can see the full -Fs/2 to Fs/2 bandwidth of that signal and also all the slower signals in my design. I'm not 100% sure what you mean with the errors that you are getting. Remember that you have to correctly specify output rates on a black box. This might be causing the problems... FIR Compiler is in Coregen and is used in System Generator when you drop the FIR Compiler block into your design. Hope this helps. CheersArticle: 121666
Jon Beniston wrote: >> A quick sum-up would include: MicroBlaze, Nios-II, > > Since when were these open source? > For microblaze since the 11 october 2006 ;) http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/f26991bc41bd42bd/ee347c3e854061b3?lnk=gst&q=Microblaze+source&rnum=10#ee347c3e854061b3 SylvainArticle: 121667
On Jul 11, 4:37 pm, Sylvain Munaut <tnt-at-246tNt- dot-...@youknowwhattodo.com> wrote: > Jon Beniston wrote: > >> A quick sum-up would include: MicroBlaze, Nios-II, > > > Since when were these open source? > > For microblaze since the 11 october 2006 ;) > > http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/f2699... > > Sylvain OK, my apologies for the Microblaze, that was a strange story :) But regarding Nios-II, i think the sources are there, but just not portable across other FPGA architectures. Am I right? Nikolaos KavvadiasArticle: 121668
On 11 Jul, 14:48, Uncle Noah <n...@skiathos.physics.auth.gr> wrote: > On Jul 11, 4:37 pm, Sylvain Munaut <tnt-at-246tNt- > > dot-...@youknowwhattodo.com> wrote: > > Jon Beniston wrote: > > >> A quick sum-up would include: MicroBlaze, Nios-II, > > > > Since when were these open source? > > > For microblaze since the 11 october 2006 ;) > > >http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/f2699... > > > Sylvain > > OK, my apologies for the Microblaze, that was a strange story :) > But regarding Nios-II, i think the sources are there, but just not > portable across other FPGA architectures. > Am I right? Sure, you can buy access to the source in the same way you can buy the source to an ARM. Not quite Open Source though. I think Xilinx do have HDL source for MicroBlaze, but it isn't that much cheaper than buying a license for a real CPU that comes with support ;-) Cheers, JonArticle: 121669
Thanks everyone, for the replies. My question was vague and poorly worded because I don't have a good grasp on what constitutes a "FPGA CPU-core"and an "ASIC CPU-core." Microblaze and Nios-II obviously are architected around the unique device-features of their respective vendors. But when it comes to the Opensource offerrings, I didn't see the same trend (maybe I didn't look close enough?) Picoblaze -- is that safe for ASIC-use? I was under the impression Xilinx's license-agreement limits it to Xilinx devices only.Article: 121670
On Jul 11, 4:56 pm, "Xilinx User" <anonym...@net.com> wrote: > Thanks everyone, for the replies. My question was vague and poorly > worded because I don't have a good grasp on what constitutes a > "FPGA CPU-core"and an "ASIC CPU-core." Microblaze and Nios-II > obviously are architected around the unique device-features of their > respective vendors. But when it comes to the Opensource offerrings, > I didn't see the same trend (maybe I didn't look close enough?) > > Picoblaze -- is that safe for ASIC-use? I was under the impression > Xilinx's license-agreement limits it to Xilinx devices only. I'm not sure about the Picoblaze licensing. Actually, there are at least 2 distinct version of Picoblaze available from Xilinx site. There is a Virtex-2/Spartan-3 optimized version (KCPSM3) that involves Xilinx-specific components (buffers, registers etc), and another version with some differences in the architecture (slightly older instruction set, 8 registers instead of 16) originally devised for CPLDs. However this description is completely portable across different FPGA vendors. For example i have ported this one to XC3S200 with good results (around 170 slices, maybe less i don't recall the exact results). It would be meaningful for Xilinx to license this more obsolete version in GPL or LGPL sense. Anyone aware of the exact licensing issues with the two different PicoBlaze versions, please jump in. Nikolaos KavvadiasArticle: 121671
I have received the following error warning: Cpld:828 - Signal 'done.RSTF' has been minimized to 'GND'. Waiting with antissipation, ThanksArticle: 121672
All, And, the MicroBlaze(tm) uP soft core use agreement stipulates that it is to be used on Xilinx FPGAs, only. We have no incentive to allow its use in an ASIC. I think for ASIC development, the issue is all risk: as in, there must not be any risk at all. Thus, you see ARM uP's in most low power/low cost ASICs. The 'guarantee' allows one to get real support (which is sadly lacking in open cores). Higher end/higher performance ASICs use MIPs, or the PowerPC. Recently opencores.org put itself up for sale, and is (effectively) out of business. This is exactly why using open cores represents a huge risk. Since no one has figured out how to make money off open cores, there is no incentive at all to give your hard work away for free. Additionally, a massive amount of work goes into testing and re-optimizing every core when the technology node changes. Who will pay for that? Who will warrant or guarantee operation? Who supplies the test bench vectors to verify proper operation? AustinArticle: 121673
X-User, PicoBlaze is offered "as - is", and subsequently has no restrictions on its use. It is in the 'spirit' of an open core, as in, we really do not mind where and how it may be used. It is also "unsupported" by the Xilinx Support system. If we find something that is a bug, we will fix it, but we do not offer any guarantees about its use, or performance like we do for the MicroBlaze(tm) or PowerPC(tm) processors. http://www.xilinx.com/bvdocs/userguides/ug129.pdf AustinArticle: 121674
On Jul 11, 3:25 pm, austin <aus...@xilinx.com> wrote: > X-User, > > PicoBlaze is offered "as - is", and subsequently has no restrictions on > its use. > > It is in the 'spirit' of an open core, as in, we really do not mind > where and how it may be used. > > It is also "unsupported" by the Xilinx Support system. If we find > something that is a bug, we will fix it, but we do not offer any > guarantees about its use, or performance like we do for the > MicroBlaze(tm) or PowerPC(tm) processors. > > http://www.xilinx.com/bvdocs/userguides/ug129.pdf > > Austin Austin, it looks like you dont know what you are talking about: ASFAIK PicoBlaze is under XDL License - http://www.xilinx.com/bvdocs/appnotes/Design_License.pdf those it is resctricted for the use in Xilinx devices only. => this is not OPEN SOURCE and FREE FOR ANY USE ! so if you dont care in what silicon it is used thats fine, but officially Xilinx lawers could prevent ASICs with PicoBlaze inside from being used. or is there any other way to understand the XDL terms? Antti
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