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,
i am working on the following code but i have error as:
"Bad condition in wait statement, or only one clock per process."
Code:
Sensor_fusion_1_output : PROCESS
VARIABLE z : vector_of_real(0 TO 11);
VARIABLE xapriori : vector_of_real(0 TO 11);
VARIABLE residual : vector_of_real(0 TO 11);
VARIABLE papriori : vector_of_real(0 TO 11);
VARIABLE K : vector_of_real(0 TO 11);
VARIABLE paposteriori : vector_of_real(0 TO 11);
VARIABLE xaposteriori1 : vector_of_real(0 TO 11);
VARIABLE add_temp : real;
VARIABLE div_temp : real;
VARIABLE add_temp_0 : vector_of_real(0 TO 10);
VARIABLE div_temp_0 : vector_of_real(0 TO 10);
BEGIN
z := temp;
xapriori := (OTHERS => 0.0);
residual := (OTHERS => 0.0);
papriori := (OTHERS => 0.0);
K := (OTHERS => 0.0);
paposteriori := (OTHERS => 0.0);
xaposteriori1 := (OTHERS => 0.0);
xapriori(0) := 0.0;
residual(0) := z(0);
papriori(0) := 4.3;
add_temp := 4.3 + 0.1;
IF add_temp = 0.0 THEN
div_temp := C_divbyzero_p;
ELSE
div_temp := One / add_temp;
END IF;
K(0) := div_temp;
paposteriori(0) := 4.3 * (1.0 - K(0));
xaposteriori1(0) := K(0) * z(0);
FOR k_0 IN 0 TO 10 LOOP
xapriori(1 + k_0) := xaposteriori1(k_0);
residual(1 + k_0) := z(1 + k_0) - xapriori(1 + k_0);
papriori(1 + k_0) := paposteriori(k_0) + 2.8;
add_temp_0(k_0) := papriori(1 + k_0) + 0.1;
IF add_temp_0(k_0) = 0.0 THEN
IF (papriori(1 + k_0) < 0.0) XOR (add_temp_0(k_0) < 0.0) THEN
div_temp_0(k_0) := C_divbyzero_n;
ELSE
div_temp_0(k_0) := C_divbyzero_p;
END IF;
ELSE
div_temp_0(k_0) := papriori(1 + k_0) / add_temp_0(k_0);
END IF;
K(1 + k_0) := div_temp_0(k_0);
paposteriori(1 + k_0) := papriori(1 + k_0) * (1.0 - K(1 + k_0));
xaposteriori1(1 + k_0) := xapriori(1 + k_0) + (K(1 + k_0) * residual(1 + k_0));
END LOOP;
xaposteriori <= xaposteriori1;
WAIT;
END PROCESS Sensor_fusion_1_output;
Can anyone help me.Please....
Thank you.
Article: 157801On Mon, 30 Mar 2015 04:54:12 -0500, ashwini012 wrote: > Hi, > i am working on the following code but i have error as: > > "Bad condition in wait statement, or only one clock per process." > > Code: > > Sensor_fusion_1_output : PROCESS > VARIABLE z : vector_of_real(0 TO 11); ... > > BEGIN > > z := temp; > > WAIT; > > END PROCESS Sensor_fusion_1_output; > Can anyone help me.Please.... > > Thank you. It would help if you mentioned which tool reported these errors. I presume you know that this code is for simulation only, and cannot be synthesised, right? But I can't see anything wrong with it for simulation, other than it will only run once, probably before any other signals had valid values. -- BrianArticle: 157802
On Friday, March 27, 2015 at 7:23:57 PM UTC-7, rickman wrote: > On 3/27/2015 7:22 PM, darol.klawetter@gmail.com wrote: > > On Friday, March 27, 2015 at 5:14:44 PM UTC-5, nobody wrote: > >> First, thank you for taking the time to consider the questions I have = not answered. > >> I am working on a 32 bit serial to 32 bit parallel port which reads fr= om an ADC. Currently looking to find a better solution, and I searched for = predefined vhdl module with little success. I stumbled upon Macros, SR16CE,= which utilize primitives but they seem to be schematic oriented and not av= ailable inside the ISE 8.2i, windows xp os. > >> > >> Question: Do common VHDL constructs exist in some library within the X= ilinx folder file structure? > >> > >> Stumbling onto some help files within Xilinx website,http://www.csit-s= un.pub.ro/courses/Masterat/Xilinx%20Synthesis%20Technology/toolbox.xilinx.c= om/docsan/xilinx4/data/docs/xst/hdlcode8.html, I found what I think I was l= ooking for, however I need some help interpreting the VHDL statement that d= oes everything, [line 13]: > >> > >> 8-bit Shift-Left Register with Positive-Edge Clock, Serial In, and Par= allel Out > >> Note For this example XST will infer SRL16. > >> > >> 1.library ieee; > >> 2.use ieee.std_logic_1164.all; > >> > >> 3.entity shift is > >> 4. port(C, SI : in std_logic; > >> 5. PO : out std_logic_vector(7 downto 0)); > >> 6.end shift; > >> 7.architecture archi of shift is > >> 8. signal tmp: std_logic_vector(7 downto 0); > >> 9. begin > >> 10. process (C) > >> 11. begin > >> 12. if (C'event and C=3D'1') then > >> 13. tmp <=3D tmp(6 downto 0)& SI; > >> 14. end if; > >> 15. end process; > >> 16. PO <=3D tmp; > >> 17.end archi; > >> > >> Question:How does line 13 seem to do so much? > > > > The "&" symbol in Line 13 is the concatenation operator. Line 13 perfor= ms the shift by concatenating the lower 7 bits of the shift register with t= he serial input, SI. This results in SI becoming bit 0 of tmp and bit 7 of = tmp being discarded. Hope this helps. >=20 > Yes, that is a fairly straightforward expression of the shift function.= =20 > The question is whether your tool will be able to infer the use of two= =20 > SRL16s. Actually, I don't think an SRL16 is at all appropriate for a=20 > serial to parallel converter since it doesn't have a parallel output.=20 > The SRL16 is serial buffer, 1 bit in and 1 bit out. >=20 > If you look at the various sections on this page they list examples some= =20 > of which say they *will* infer SRL16s and some say they *will not* infer= =20 > SRL16s. I think they made a mistake and left out the *not* for the=20 > section showing this code. This is *not* Xilinx vetted info. It is a=20 > third party source with unknown credentials. I believe any of the code= =20 > shown involving parallel input or output will not be inferred using SRL16= s. >=20 > Look at this app note and I think you will see the limitation of the=20 > SRL16s. >=20 > http://www.xilinx.com/support/documentation/application_notes/xapp465.pdf >=20 > So the above code will work just fine. It just won't, and in fact,=20 > *can't* use an SRL16. >=20 > Someone please correct me if I am wrong. >=20 > --=20 >=20 > Rick Thank you for you time. I had similar thoughts having read xapp465. I guess= that still leaves me with needing a helpful solution toward utilizing a se= rial to parallel hardware, which would seem very common and tucked away in = some library somewhere. I came across the use of macros, but are based on g= raphical symbols, schematics, and not VHDL. The macors seemed to be based o= n the SR16CE but I have not been able to find hide nor hair of such a beast= . Thank you!Article: 157803
On Monday, March 30, 2015 at 9:01:28 AM UTC-7, nobody wrote: > On Friday, March 27, 2015 at 7:23:57 PM UTC-7, rickman wrote: > > On 3/27/2015 7:22 PM, darol.klawetter@gmail.com wrote: > > > On Friday, March 27, 2015 at 5:14:44 PM UTC-5, nobody wrote: > > >> First, thank you for taking the time to consider the questions I hav= e not answered. > > >> I am working on a 32 bit serial to 32 bit parallel port which reads = from an ADC. Currently looking to find a better solution, and I searched fo= r predefined vhdl module with little success. I stumbled upon Macros, SR16C= E, which utilize primitives but they seem to be schematic oriented and not = available inside the ISE 8.2i, windows xp os. > > >> > > >> Question: Do common VHDL constructs exist in some library within the= Xilinx folder file structure? > > >> > > >> Stumbling onto some help files within Xilinx website,http://www.csit= -sun.pub.ro/courses/Masterat/Xilinx%20Synthesis%20Technology/toolbox.xilinx= .com/docsan/xilinx4/data/docs/xst/hdlcode8.html, I found what I think I was= looking for, however I need some help interpreting the VHDL statement that= does everything, [line 13]: > > >> > > >> 8-bit Shift-Left Register with Positive-Edge Clock, Serial In, and P= arallel Out > > >> Note For this example XST will infer SRL16. > > >> > > >> 1.library ieee; > > >> 2.use ieee.std_logic_1164.all; > > >> > > >> 3.entity shift is > > >> 4. port(C, SI : in std_logic; > > >> 5. PO : out std_logic_vector(7 downto 0)); > > >> 6.end shift; > > >> 7.architecture archi of shift is > > >> 8. signal tmp: std_logic_vector(7 downto 0); > > >> 9. begin > > >> 10. process (C) > > >> 11. begin > > >> 12. if (C'event and C=3D'1') then > > >> 13. tmp <=3D tmp(6 downto 0)& SI; > > >> 14. end if; > > >> 15. end process; > > >> 16. PO <=3D tmp; > > >> 17.end archi; > > >> > > >> Question:How does line 13 seem to do so much? > > > > > > The "&" symbol in Line 13 is the concatenation operator. Line 13 perf= orms the shift by concatenating the lower 7 bits of the shift register with= the serial input, SI. This results in SI becoming bit 0 of tmp and bit 7 o= f tmp being discarded. Hope this helps. Darol, Thank you, that was helpful! CyArticle: 157804
rickman <gnuarm@gmail.com> wrote: > On 3/27/2015 7:22 PM, darol.klawetter@gmail.com wrote: (snip) >>> I am working on a 32 bit serial to 32 bit parallel port which >>> reads from an ADC. (snip) > Yes, that is a fairly straightforward expression of the shift function. > The question is whether your tool will be able to infer the use of two > SRL16s. Actually, I don't think an SRL16 is at all appropriate for a > serial to parallel converter since it doesn't have a parallel output. > The SRL16 is serial buffer, 1 bit in and 1 bit out. Yes, but I think you can select which bit it is. It will at least make constant length shift registers with lengths other than 16. The logic is similar to the usual LUT logic, but with the ability to shift the bits in the LUT (RAM). > If you look at the various sections on this page they list examples some > of which say they *will* infer SRL16s and some say they *will not* infer > SRL16s. I think they made a mistake and left out the *not* for the > section showing this code. This is *not* Xilinx vetted info. It is a > third party source with unknown credentials. I believe any of the code > shown involving parallel input or output will not be inferred using SRL16s. I am not so good at figuring out Xilinx primitives, but I did figure out how to use a clock generator as a Xilinx primitive. I think you should be able to generate a shift register, counter, and multiplexer, to shift and then select which bit to send out. It might take primitives to do that, though. -- glenArticle: 157805
On 3/30/2015 12:01 PM, nobody wrote: > On Friday, March 27, 2015 at 7:23:57 PM UTC-7, rickman wrote: >> On 3/27/2015 7:22 PM, darol.klawetter@gmail.com wrote: >>> On Friday, March 27, 2015 at 5:14:44 PM UTC-5, nobody wrote: >>>> First, thank you for taking the time to consider the questions I have not answered. >>>> I am working on a 32 bit serial to 32 bit parallel port which reads from an ADC. Currently looking to find a better solution, and I searched for predefined vhdl module with little success. I stumbled upon Macros, SR16CE, which utilize primitives but they seem to be schematic oriented and not available inside the ISE 8.2i, windows xp os. >>>> >>>> Question: Do common VHDL constructs exist in some library within the Xilinx folder file structure? >>>> >>>> Stumbling onto some help files within Xilinx website,http://www.csit-sun.pub.ro/courses/Masterat/Xilinx%20Synthesis%20Technology/toolbox.xilinx.com/docsan/xilinx4/data/docs/xst/hdlcode8.html, I found what I think I was looking for, however I need some help interpreting the VHDL statement that does everything, [line 13]: >>>> >>>> 8-bit Shift-Left Register with Positive-Edge Clock, Serial In, and Parallel Out >>>> Note For this example XST will infer SRL16. >>>> >>>> 1.library ieee; >>>> 2.use ieee.std_logic_1164.all; >>>> >>>> 3.entity shift is >>>> 4. port(C, SI : in std_logic; >>>> 5. PO : out std_logic_vector(7 downto 0)); >>>> 6.end shift; >>>> 7.architecture archi of shift is >>>> 8. signal tmp: std_logic_vector(7 downto 0); >>>> 9. begin >>>> 10. process (C) >>>> 11. begin >>>> 12. if (C'event and C='1') then >>>> 13. tmp <= tmp(6 downto 0)& SI; >>>> 14. end if; >>>> 15. end process; >>>> 16. PO <= tmp; >>>> 17.end archi; >>>> >>>> Question:How does line 13 seem to do so much? >>> >>> The "&" symbol in Line 13 is the concatenation operator. Line 13 performs the shift by concatenating the lower 7 bits of the shift register with the serial input, SI. This results in SI becoming bit 0 of tmp and bit 7 of tmp being discarded. Hope this helps. >> >> Yes, that is a fairly straightforward expression of the shift function. >> The question is whether your tool will be able to infer the use of two >> SRL16s. Actually, I don't think an SRL16 is at all appropriate for a >> serial to parallel converter since it doesn't have a parallel output. >> The SRL16 is serial buffer, 1 bit in and 1 bit out. >> >> If you look at the various sections on this page they list examples some >> of which say they *will* infer SRL16s and some say they *will not* infer >> SRL16s. I think they made a mistake and left out the *not* for the >> section showing this code. This is *not* Xilinx vetted info. It is a >> third party source with unknown credentials. I believe any of the code >> shown involving parallel input or output will not be inferred using SRL16s. >> >> Look at this app note and I think you will see the limitation of the >> SRL16s. >> >> http://www.xilinx.com/support/documentation/application_notes/xapp465.pdf >> >> So the above code will work just fine. It just won't, and in fact, >> *can't* use an SRL16. >> >> Someone please correct me if I am wrong. >> >> -- >> >> Rick > > Thank you for you time. I had similar thoughts having read xapp465. I guess that still leaves me with needing a helpful solution toward utilizing a serial to parallel hardware, which would seem very common and tucked away in some library somewhere. I came across the use of macros, but are based on graphical symbols, schematics, and not VHDL. The macors seemed to be based on the SR16CE but I have not been able to find hide nor hair of such a beast.. Thank you! I'm not sure what you are trying to do. The code you have above will do the job of a serial to parallel shift register. Why do you need to worry about which primitives get used in the FPGA? -- RickArticle: 157806
Brian Drummond <brian@shapes.demon.co.uk> writes: > Well, Intel were Altera's 'second source' (back when that mattered) and > (if I'm not mistaken) their original fab back in about 1983 - which is > where the "Intel FPGAs" mentioned in another post came from. > > So there's quite a long association there. Wasn't there also some kind of Intel Atom + Altera FPGA on the same chip? Ah yes, the Stellarton. http://www.eetimes.com/document.asp?doc_id=1257969 I guess those weren't huge sellers... But last summer Intel announced some upcoming Xeons with FPGA logic on board. No doubt targeting the server markets where FPGA coprocessors have made appearances recently.Article: 157807
On 3/31/2015 3:30 AM, Anssi Saari wrote: > Brian Drummond <brian@shapes.demon.co.uk> writes: > >> Well, Intel were Altera's 'second source' (back when that mattered) and >> (if I'm not mistaken) their original fab back in about 1983 - which is >> where the "Intel FPGAs" mentioned in another post came from. >> >> So there's quite a long association there. > > Wasn't there also some kind of Intel Atom + Altera FPGA on the same > chip? Ah yes, the > Stellarton. http://www.eetimes.com/document.asp?doc_id=1257969 > > I guess those weren't huge sellers... But last summer Intel announced > some upcoming Xeons with FPGA logic on board. No doubt targeting the > server markets where FPGA coprocessors have made appearances recently. I thought that was two die in the same package, no? Reading your article the term, "system-in-package" indicates multiple die. It think the advantage is in reducing the system size and having a very direct connection between the two chips. Putting them on one die would likely make a faster connection possible, but would be much more difficult to pair in various combinations. That's the big reason why FPGA makers have resisted for so long incorporating CPUs on the FPGA chip until recently. -- RickArticle: 157808
On 31/03/15 08:30, Anssi Saari wrote: > Brian Drummond <brian@shapes.demon.co.uk> writes: > >> Well, Intel were Altera's 'second source' (back when that mattered) and >> (if I'm not mistaken) their original fab back in about 1983 - which is >> where the "Intel FPGAs" mentioned in another post came from. >> >> So there's quite a long association there. > > Wasn't there also some kind of Intel Atom + Altera FPGA on the same > chip? Ah yes, the > Stellarton. http://www.eetimes.com/document.asp?doc_id=1257969 > > I guess those weren't huge sellers... But last summer Intel announced > some upcoming Xeons with FPGA logic on board. No doubt targeting the > server markets where FPGA coprocessors have made appearances recently. More likely Intel wants to head off the market which has ARM processor(s) plus custom glue logic. Target: highly-integrated low-power server farms.Article: 157809
On Saturday, March 28, 2015 at 3:54:12 AM UTC-4, rickman wrote: > On 3/28/2015 1:38 AM, Rob Doyle wrote: > > On 3/27/2015 2:28 PM, Tim Wescott wrote: > >> On Fri, 27 Mar 2015 14:50:23 -0500, "" wrote: > >> > >>> http://www.wsj.com/articles/intel-in-talks-to-buy-altera-1427485172 > >>> --------------------------------------- > >>> Posted through http://www.FPGARelated.com > >> > >> Hmm. While I have tons of respect for Intel as a company that makes > >> stuff > >> that people will buy, I'm old enough to have seen more than one > >> generation > >> of Intel embedded processors go by the wayside when the PC market picked > >> up. > >> > >> So I don't trust Intel's attention span vis-a-vis whatever they happen to > >> think their core business is. If they kept Altera as an easily-spun-off > >> business unit, and kept it supported, then I could see them spinning it > >> off again when the PC market did pick up, or by some miracle they managed > >> to make cell phone processors that actually worked, or something. > >> > > > > Not just embedded processors... > > > > It wouldn't be the first time Intel was in the programmable logic business. > > > > http://www.dataman.com/media/datasheet/Intel/5C090.pdf > > http://www.dataman.com/media/datasheet/Intel/5C060.pdf > > https://docs.google.com/file/d/0B9rh9tVI0J5mSzhDNUVpeVcyNDA/edit > > > > Didn't Altera buy Intel's PLD business back in the '90s??? > > > > Sorry. I don't see how this could be a good thing for Altera. > > Yeah, I'm concerned too. I'm hoping that Altera is big enough that > Intel won't want to mess with them and destroy the company. > > I think those data sheets are from the days when dinosaurs roamed the > FPGA earth and was Intel's own attempt to enter the market. I have no > idea why they actually bailed. I can only assume the competition was > stiff then with a number of startups including Neocad providing the > place and route software for a number of these companies. Xilinx has > said they spend more on software development than they do developing the > hardware. Several of these companies dropped their in house software > development due to the huge cost. Maybe Intel dropped the product line > because of it. But much more recently they were working with a company > to produce some much more advanced product which I believe may still be > operating using Intel's fab technology, or has it also gone belly up? I > don't recall the name. > > Looks like Intel likes the Altera approach and want to keep it, literally. > > -- > > Rick Intel acquired Wind River back in '09 but they've left them alone as a separate entity, so we can only hope they do the same with Altera. http://www.windriver.com/news/press/pr.html?ID=7081Article: 157810
rickman <gnuarm@gmail.com> writes: > I thought that was two die in the same package, no? Reading your > article the term, "system-in-package" indicates multiple die. It > think the advantage is in reducing the system size and having a very > direct connection between the two chips. Putting them on one die > would likely make a faster connection possible, but would be much more > difficult to pair in various combinations. I agree with the separate die part. > That's the big reason why FPGA makers have resisted for so long > incorporating CPUs on the FPGA chip until recently. Uh, resisted? Xilinx had the Virtex 2 and 4 Pros with integrated PowerPC cores around a decade ago and I'm pretty sure that was single die. I was involved in such a project in 2006, Virtex 4 Pro was new then and Virtex 2 Pro came out around 2002 I think (from the data sheet dates). Altera had a similar thing, Excalibur I think? I have to assume those weren't big sellers either since they pretty much disappeared. I have to assume they weren't resisting to offer these. My guess would be they couldn't offer them at competitive prices. Maybe the new generation is doing better in that regard.Article: 157811
On 3/31/2015 4:19 PM, Anssi Saari wrote: > rickman <gnuarm@gmail.com> writes: > >> I thought that was two die in the same package, no? Reading your >> article the term, "system-in-package" indicates multiple die. It >> think the advantage is in reducing the system size and having a very >> direct connection between the two chips. Putting them on one die >> would likely make a faster connection possible, but would be much more >> difficult to pair in various combinations. > > I agree with the separate die part. > >> That's the big reason why FPGA makers have resisted for so long >> incorporating CPUs on the FPGA chip until recently. > > Uh, resisted? Xilinx had the Virtex 2 and 4 Pros with integrated PowerPC > cores around a decade ago and I'm pretty sure that was single die. I was > involved in such a project in 2006, Virtex 4 Pro was new then and Virtex > 2 Pro came out around 2002 I think (from the data sheet dates). Yeah, they had those and Altera had an ARM and Atmel had a... I think maybe an AVR on the die with the FPGA. But they all let them die rather than continue the part in the next generation. When asked Xilinx people in particular (who used to be very vocal in this group... in fact, too vocal which is why they aren't here anymore) said the problem was the many combinations of CPU, RAM and FPGA that would be required, not to mention the packaging. Seems they don't play the same game the MCU makers do who regularly have dozens if not hundreds of combinations of any given processor. Also, this was the era when all FPGAs were power hungry and expensive. So yeah, they resisted the rest of the market who would have loved *affordable* FPGAs with CPUs. The FPGA makers could have done it, but they chose not to address that market because they were after the *big* bucks at the high end. > Altera had a similar thing, Excalibur I think? I have to assume those > weren't big sellers either since they pretty much disappeared. > > I have to assume they weren't resisting to offer these. My guess would > be they couldn't offer them at competitive prices. Maybe the new > generation is doing better in that regard. I think the difference is that their market is determined by pretty much one industry, comms. When they say they would like to see a part, A and X reply, "Will Tuesday be soon enough?" I expect *that* market reached a point where the integrated ARM was powerful enough and needed tightly coupled enough that it became a worthwhile part. I know the FPGA companies have all been chasing the high volume markets like automotive and even phones and tablets. But all of these guys have volumes that just don't make sense for FPGAs 99% of the time. Comms is where the FPGA profit is and will be for some time to come. -- RickArticle: 157812
>>Hi everyone,
>>
>>I apologize if this is maybe not the best audience for these kind of
>>enquiries but I'll try anyhow.
>>
>>I'm looking for a good SystemC/TLM 2.0 training course which is not too
>>basic and can give me a head start for a real life project.
>>
>>I'm not a black belt on C++ but I'm familiar with most of its concepts
>>on top of C (which I use quite often instead). Since we have a budget
>>for training in our company I'd like to make something useful out of it
>>and given the current issues we are facing in architecting systems of
>>increasingly complex features set, I believe that modeling would add
>>value to our products and avoid many issues due to a wrong architecture.
>>
>>Any ideas/suggestions?
>>
>>p.s.: I've no problems to start some reading/testing by myself in order
>>to fill the gap before attending the course.
>>
>>--
>>A: Because it messes up the order in which people normally read text.
>>Q: Why is top-posting such a bad thing?
>>A: Top-posting.
>>Q: What is the most annoying thing on usenet and in e-mail?
>
>-------------------------------------------------
>You may want to take a look on these simple systemc examples:
>My First systemC program
>systemC debug with SC_TIME Tip
>Simple multiplier and a test-bench in systemC
>ETHERNET packet scv RANDOMIZATION in systemC
>http://bknpk.ddns.net/my_web/MiscellaneousHW/MiscellaneousHW.html
>
>
>---------------------------------------
>Posted through http://www.FPGARelated.com
I recently studied the simple_bus example from systemc. It has not been
converted to TLM, but still is a good example. To compile and run it, you
may want to take a look at:
http://bknpk.ddns.net/my_web/SystemC_MyFirst/sysc_simple_bus_Makefile.html
Another issue that may interest you is SCV. It allows to write constraints
in a system verilog style:
SCV_CONSTRAINT_CTOR(my_constraint) {
SCV_CONSTRAINT ( a() * a() + b() * b() == c() * c());
SCV_CONSTRAINT( a() > 0 && b() > 0 );
}
A simple example as well as makefile for compilation can be seen at:
http://bknpk.ddns.net/my_web/SystemC_MyFirst/scv_cmp_err_pop_constraint.html
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 157813On Wed, 01 Apr 2015 01:16:30 -0400, rickman wrote: > On 3/31/2015 4:19 PM, Anssi Saari wrote: >> rickman <gnuarm@gmail.com> writes: >> >>> I thought that was two die in the same package, no? Reading your >>> article the term, "system-in-package" indicates multiple die. It >>> think the advantage is in reducing the system size and having a very >>> direct connection between the two chips. Putting them on one die >>> would likely make a faster connection possible, but would be much more >>> difficult to pair in various combinations. >> >> I agree with the separate die part. >> >>> That's the big reason why FPGA makers have resisted for so long >>> incorporating CPUs on the FPGA chip until recently. >> >> Uh, resisted? Xilinx had the Virtex 2 and 4 Pros with integrated >> PowerPC cores around a decade ago and I'm pretty sure that was single >> die. I was involved in such a project in 2006, Virtex 4 Pro was new >> then and Virtex 2 Pro came out around 2002 I think (from the data sheet >> dates). > > Yeah, they had those and Altera had an ARM and Atmel had a... I think > maybe an AVR on the die with the FPGA. But they all let them die rather > than continue the part in the next generation. <balance snipped> I was on a project that gave those parts a serious look. We ended up using a plain old FPGA talking to a processor. Partially this was because we had a ton of boards that were all using that same processor but without the FPGA, but partially this was because we didn't see a great big advantage in terms of project hours to the embedded processor. I have thought for a long time that instead of hugely complicated, specialized peripherals, a chip that has a processor with an FPGA mapped to the peripheral space could have some use -- it seems like you never have the peripherals you'd really like, unless you have a whole bunch of peripherals just sitting there sleeping. There's probably a ton of practical reasons why it's a dumb idea. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157814
> I have thought for a long time that instead of hugely complicated, > specialized peripherals, a chip that has a processor with an FPGA mapped > to the peripheral space could have some use -- it seems like you never > have the peripherals you'd really like, unless you have a whole bunch of > peripherals just sitting there sleeping. There's probably a ton of > practical reasons why it's a dumb idea. There are two popular products on both ends of the spectrum that have been around for years: microcontrollers with programmable logic peripherals (for example, Cypress PSOC) and a microcontroller core implemented on an FPGA (for example, Altera NIOS). I've used both example products with great success. As you said, it's real convenient to roll your own peripherals with impunity. It saved me hours of coding effort when you can smartly implement the peripheral of your dreams with a little HW design. JJSArticle: 157815
On 4/1/2015 1:27 PM, John Speth wrote: >> I have thought for a long time that instead of hugely complicated, >> specialized peripherals, a chip that has a processor with an FPGA mapped >> to the peripheral space could have some use -- it seems like you never >> have the peripherals you'd really like, unless you have a whole bunch of >> peripherals just sitting there sleeping. There's probably a ton of >> practical reasons why it's a dumb idea. > > There are two popular products on both ends of the spectrum that have > been around for years: microcontrollers with programmable logic > peripherals (for example, Cypress PSOC) and a microcontroller core > implemented on an FPGA (for example, Altera NIOS). Calling the PSOC circuitry "programmable logic" is a bit of a stretch. Yeah, I guess technically it is logic and it is "programmable", but it is not at all general purpose. In some devices it has been dumbed down to the point of being configurable serial devices that can be a UART, SPI or similar devices, sort of a super USART... not really much like FPGAs or even PLDs. Even the parts that have some programmable elements are not terribly flexible. > I've used both example products with great success. As you said, it's > real convenient to roll your own peripherals with impunity. It saved me > hours of coding effort when you can smartly implement the peripheral of > your dreams with a little HW design. The part that gets me about the newer versions of this theme is that they are large, pricey FPGAs and incorporate fairly high end CPUs which are typically programmed under Linux... a very far cry from the efficient solution I would like to see. There are few engineers who can even design the entire system on that chip spanning logic design and system programming. -- RickArticle: 157816
On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote: > On 4/1/2015 1:27 PM, John Speth wrote: >> I've used both example products with great success. As you said, it's >> real convenient to roll your own peripherals with impunity. It saved >> me hours of coding effort when you can smartly implement the peripheral >> of your dreams with a little HW design. > > The part that gets me about the newer versions of this theme is that > they are large, pricey FPGAs and incorporate fairly high end CPUs which > are typically programmed under Linux... a very far cry from the > efficient solution I would like to see. There are few engineers who can > even design the entire system on that chip spanning logic design and > system programming. Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of which have big monster Cortex A9s meant to run Linux with a mess of DRAM and etc. Which, I mean we can make work. But if I could get a 10-20KLUT FPGA with a dual or quad Cortex M4 instead? Nice and light with every intention of running bare metal with 10-20K of code? I'd take it in a heartbeat. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 157817
On 02/04/2015 00:10, rickman wrote: > The part that gets me about the newer versions of this theme is that > they are large, pricey FPGAs and incorporate fairly high end CPUs which > are typically programmed under Linux... a very far cry from the > efficient solution I would like to see. There are few engineers who can > even design the entire system on that chip spanning logic design and > system programming. > Is there any info on the price range for the latest Xilinx UltraScale+ parts?Article: 157818
On 4/1/2015 7:27 PM, Rob Gaddi wrote: > On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote: > >> On 4/1/2015 1:27 PM, John Speth wrote: > >>> I've used both example products with great success. As you said, it's >>> real convenient to roll your own peripherals with impunity. It saved >>> me hours of coding effort when you can smartly implement the peripheral >>> of your dreams with a little HW design. >> >> The part that gets me about the newer versions of this theme is that >> they are large, pricey FPGAs and incorporate fairly high end CPUs which >> are typically programmed under Linux... a very far cry from the >> efficient solution I would like to see. There are few engineers who can >> even design the entire system on that chip spanning logic design and >> system programming. > > Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of > which have big monster Cortex A9s meant to run Linux with a mess of DRAM > and etc. Which, I mean we can make work. But if I could get a 10-20KLUT > FPGA with a dual or quad Cortex M4 instead? Nice and light with every > intention of running bare metal with 10-20K of code? I'd take it in a > heartbeat. Learn Forth and make that 4 to 8 KB of code. Which brings us to the possible reason they don't make the lower end CPUs in an FPGA... it competes against soft cores which can do the job you describe very well. There are fast, efficient CPU cores which run at 100 MIPS and use under 1000 LUTs, not so much in your 10-20 kLUT device, eh? Very probably cheaper in the long run than a chip with hard cores. If you want to run bare-metal quick and easy, check out the J1 Forth CPU by James Bowman. I've rolled my own similar CPUs and I really like his design. http://www.excamera.com/sphinx/fpga-j1.html Just as a point of comparison, the GA144 is a bit like an FPGA but uses tiny 18 bit processors as logic elements, 144 of them. It pretty well sucks in many regards... well, "sucks" is a poor choice of words I guess. But they had a cool idea of the tiny processors and connecting them in a net, but then totally forgot to consider any applications when designing a chip around it. http://www.greenarraychips.com/home/products/ -- RickArticle: 157819
On 4/1/15 7:27 PM, Rob Gaddi wrote: > On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote: > >> On 4/1/2015 1:27 PM, John Speth wrote: > >>> I've used both example products with great success. As you said, it's >>> real convenient to roll your own peripherals with impunity. It saved >>> me hours of coding effort when you can smartly implement the peripheral >>> of your dreams with a little HW design. >> >> The part that gets me about the newer versions of this theme is that >> they are large, pricey FPGAs and incorporate fairly high end CPUs which >> are typically programmed under Linux... a very far cry from the >> efficient solution I would like to see. There are few engineers who can >> even design the entire system on that chip spanning logic design and >> system programming. > > Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of > which have big monster Cortex A9s meant to run Linux with a mess of DRAM > and etc. Which, I mean we can make work. But if I could get a 10-20KLUT > FPGA with a dual or quad Cortex M4 instead? Nice and light with every > intention of running bare metal with 10-20K of code? I'd take it in a > heartbeat. > Have you looked at the MicroSemi "SmartFusion2" FPGAs? Its just a single M3, but that can often be enough.Article: 157820
On 4/1/2015 10:59 PM, Richard Damon wrote: > On 4/1/15 7:27 PM, Rob Gaddi wrote: >> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote: >> >>> On 4/1/2015 1:27 PM, John Speth wrote: >> >>>> I've used both example products with great success. As you said, it's >>>> real convenient to roll your own peripherals with impunity. It saved >>>> me hours of coding effort when you can smartly implement the peripheral >>>> of your dreams with a little HW design. >>> >>> The part that gets me about the newer versions of this theme is that >>> they are large, pricey FPGAs and incorporate fairly high end CPUs which >>> are typically programmed under Linux... a very far cry from the >>> efficient solution I would like to see. There are few engineers who can >>> even design the entire system on that chip spanning logic design and >>> system programming. >> >> Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of >> which have big monster Cortex A9s meant to run Linux with a mess of DRAM >> and etc. Which, I mean we can make work. But if I could get a 10-20KLUT >> FPGA with a dual or quad Cortex M4 instead? Nice and light with every >> intention of running bare metal with 10-20K of code? I'd take it in a >> heartbeat. >> > > Have you looked at the MicroSemi "SmartFusion2" FPGAs? Its just a single > M3, but that can often be enough. I had forgotten them. In fact, I can't remember any of the details other than it using an M3 and having FPGA fabric. This is a one time programmable part or a Flash part? -- RickArticle: 157821
On 4/2/15 2:06 AM, rickman wrote: > On 4/1/2015 10:59 PM, Richard Damon wrote: >> On 4/1/15 7:27 PM, Rob Gaddi wrote: >>> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote: >>> >>>> On 4/1/2015 1:27 PM, John Speth wrote: >>> >>>>> I've used both example products with great success. As you said, it's >>>>> real convenient to roll your own peripherals with impunity. It saved >>>>> me hours of coding effort when you can smartly implement the >>>>> peripheral >>>>> of your dreams with a little HW design. >>>> >>>> The part that gets me about the newer versions of this theme is that >>>> they are large, pricey FPGAs and incorporate fairly high end CPUs which >>>> are typically programmed under Linux... a very far cry from the >>>> efficient solution I would like to see. There are few engineers who >>>> can >>>> even design the entire system on that chip spanning logic design and >>>> system programming. >>> >>> Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of >>> which have big monster Cortex A9s meant to run Linux with a mess of DRAM >>> and etc. Which, I mean we can make work. But if I could get a >>> 10-20KLUT >>> FPGA with a dual or quad Cortex M4 instead? Nice and light with every >>> intention of running bare metal with 10-20K of code? I'd take it in a >>> heartbeat. >>> >> >> Have you looked at the MicroSemi "SmartFusion2" FPGAs? Its just a single >> M3, but that can often be enough. > > I had forgotten them. In fact, I can't remember any of the details > other than it using an M3 and having FPGA fabric. This is a one time > programmable part or a Flash part? > They are Flash based.Article: 157822
On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote: > On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote: >=20 > > On 4/1/2015 1:27 PM, John Speth wrote: >=20 > >> I've used both example products with great success. As you said, it's > >> real convenient to roll your own peripherals with impunity. It saved > >> me hours of coding effort when you can smartly implement the periphera= l > >> of your dreams with a little HW design. > >=20 > > The part that gets me about the newer versions of this theme is that > > they are large, pricey FPGAs and incorporate fairly high end CPUs which > > are typically programmed under Linux... a very far cry from the > > efficient solution I would like to see. There are few engineers who ca= n > > even design the entire system on that chip spanning logic design and > > system programming. >=20 > Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of= =20 > which have big monster Cortex A9s meant to run Linux with a mess of DRAM= =20 > and etc. Which, I mean we can make work. But if I could get a 10-20KLUT= =20 > FPGA with a dual or quad Cortex M4 instead? Nice and light with every=20 > intention of running bare metal with 10-20K of code? I'd take it in a=20 > heartbeat. >=20 > --=20 > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > Email address domain is currently out of order. See above to fix. Cortex-M is most useful when you have good chunk of flash on the same die. = Which, unfortunately, would be incompatible with silicon tech used for mode= rm FPGAs. DACs and SAR ADCs are also problem. Delta-sigma ADCs probably les= s so, but I am not an expert. Anyway, for apps that I acre about SAR is mor= e useful than delta-sigma. Due to all these factors small embedded solution based on Cortex-M integrat= ed into FPGA is likely to and up more complex, using more chips and more ex= pensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA. The ugly part about MCU + FPGA solution is that, unlike chips from the past= , small modern Cortex-M MCUs rarely have good bus to talk to FPGA (good=3D= simple, not to slow and not too many pins). But then again, those old 32-bi= t MCUs that had buses that I liked were in $25+ price range. For fair compa= rison I probably have to look at old 8-bitter that I never even tried to co= nnect to FPGA. Back to another reason why I think that hard ARM Cortex-M4 core in [Altera = or Xilinx] FPGA does not look as a very good proposition: The added value of M3/M4 core alone, without flash and mixed-signal periphe= rals, is not that big. After all Nios2-f core (only core, without debug sup= port and avalon-mm infrastructure around it) occupies only ~25% of the smal= lest Cyclone4 device or ~7% of the smallest Cyclone5-E and achieves compara= ble performance. As far as I am concerned, the main advantage of Cortex-M i= s a code density - significantly more code can fits on-chip. But even that = is less important if were are talking about Cyclone5 generation, because he= re the smallest member has 140 KB of embedded memory (not counting MLABs), = which is often enough.Article: 157823
On 4/2/2015 5:30 PM, already5chosen@yahoo.com wrote: > On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote: >> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote: >> >>> On 4/1/2015 1:27 PM, John Speth wrote: >> >>>> I've used both example products with great success. As you said, it's >>>> real convenient to roll your own peripherals with impunity. It saved >>>> me hours of coding effort when you can smartly implement the peripheral >>>> of your dreams with a little HW design. >>> >>> The part that gets me about the newer versions of this theme is that >>> they are large, pricey FPGAs and incorporate fairly high end CPUs which >>> are typically programmed under Linux... a very far cry from the >>> efficient solution I would like to see. There are few engineers who can >>> even design the entire system on that chip spanning logic design and >>> system programming. >> >> Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of >> which have big monster Cortex A9s meant to run Linux with a mess of DRAM >> and etc. Which, I mean we can make work. But if I could get a 10-20KLUT >> FPGA with a dual or quad Cortex M4 instead? Nice and light with every >> intention of running bare metal with 10-20K of code? I'd take it in a >> heartbeat. >> >> -- >> Rob Gaddi, Highland Technology -- www.highlandtechnology.com >> Email address domain is currently out of order. See above to fix. > > Cortex-M is most useful when you have good chunk of flash on the same die. Which, unfortunately, would be incompatible with silicon tech used for moderm FPGAs. That is a bit of nonsense unless you consider Lattice and MicroSemi to not be using "modern" FPGA processes. They include Flash in their devices for the configuration memory. > DACs and SAR ADCs are also problem. Delta-sigma ADCs probably less so, but I am not an expert. Anyway, for apps that I acre about SAR is more useful than delta-sigma. Once again you should tell that to MicroSemi... They make a mixed signal FPGA with CPU, analog and FPGA on one die. I don't use it because of the price, a bit higher than I like to see. > Due to all these factors small embedded solution based on Cortex-M integrated into FPGA is likely to and up more complex, using more chips and more expensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA. I think you are saying that an FPGA with internal MCU is not as useful as separate FPGA and MCU because the MCU will have lots of other stuff integrated that would be additional chips with the integrated approach. Clearly it doesn't have to be that ways since at least one company makes such parts. > The ugly part about MCU + FPGA solution is that, unlike chips from the past, small modern Cortex-M MCUs rarely have good bus to talk to FPGA (good=simple, not to slow and not too many pins). But then again, those old 32-bit MCUs that had buses that I liked were in $25+ price range. For fair comparison I probably have to look at old 8-bitter that I never even tried to connect to FPGA. That brings us back to the real differences between the MCU world and the typical FPGA world. MCUs are intended for apps where speed is limited by the software. FPGAs are intended for apps where speed is potentially much faster with the limitation potentially in the I/O. So a typical high end FPGA will have lots of I/O and some very fast I/O. But such an integrated MCU/FPGA device would not be intended for high end apps with Mbps I/O. The FPGA would be adding special functionality that perhaps can't be done in the MCU alone. I had a design that required exactly this sort of need and ended up having to use an FPGA with an attached CODEC since there were no MCUs which could implement one interface. The FPGA was a bit jammed up in terms of capacity (only 3 kLUT). A small soft core could do most of the work and potentially free up some space. Had a combined chip been available it would have been a breeze to implement the one interface in hardware (or maybe two) and the rest of the design in software. > Back to another reason why I think that hard ARM Cortex-M4 core in [Altera or Xilinx] FPGA does not look as a very good proposition: > The added value of M3/M4 core alone, without flash and mixed-signal peripherals, is not that big. After all Nios2-f core (only core, without debug support and avalon-mm infrastructure around it) occupies only ~25% of the smallest Cyclone4 device or ~7% of the smallest Cyclone5-E and achieves comparable performance. As far as I am concerned, the main advantage of Cortex-M is a code density - significantly more code can fits on-chip. But even that is less important if were are talking about Cyclone5 generation, because here the smallest member has 140 KB of embedded memory (not counting MLABs), which is often enough. Yep, the low end MCU on an FPGA without any of the peripherals would not be a lot more interesting than a soft core. So when will they be doing a better job of the Vulcan mind meld and getting more analog on the FPGA die? It's not like there is anything so special about FPGA logic that can't be done in analog compatible processes. Maybe you lose some density or performance, but that isn't what we are after. At least *I* am looking for a system on chip which includes some FPGA fabric. Don't think of it as an FPGA with an MCU on chip. Think of it as an MCU with FPGA fabric on chip just like the other umpty-nine peripherals they already have along with.... gasp!... 5 volt tolerance. lol -- RickArticle: 157824
On Friday, April 3, 2015 at 1:03:23 AM UTC+3, rickman wrote: > On 4/2/2015 5:30 PM, already5chosen@yahoo.com wrote: > > On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote: > >> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote: > >> > >>> On 4/1/2015 1:27 PM, John Speth wrote: > >> > >>>> I've used both example products with great success. As you said, it= 's > >>>> real convenient to roll your own peripherals with impunity. It save= d > >>>> me hours of coding effort when you can smartly implement the periphe= ral > >>>> of your dreams with a little HW design. > >>> > >>> The part that gets me about the newer versions of this theme is that > >>> they are large, pricey FPGAs and incorporate fairly high end CPUs whi= ch > >>> are typically programmed under Linux... a very far cry from the > >>> efficient solution I would like to see. There are few engineers who = can > >>> even design the entire system on that chip spanning logic design and > >>> system programming. > >> > >> Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both o= f > >> which have big monster Cortex A9s meant to run Linux with a mess of DR= AM > >> and etc. Which, I mean we can make work. But if I could get a 10-20K= LUT > >> FPGA with a dual or quad Cortex M4 instead? Nice and light with every > >> intention of running bare metal with 10-20K of code? I'd take it in a > >> heartbeat. > >> > >> -- > >> Rob Gaddi, Highland Technology -- www.highlandtechnology.com > >> Email address domain is currently out of order. See above to fix. > > > > Cortex-M is most useful when you have good chunk of flash on the same d= ie. Which, unfortunately, would be incompatible with silicon tech used for = moderm FPGAs. >=20 > That is a bit of nonsense unless you consider Lattice and MicroSemi to=20 > not be using "modern" FPGA processes. They include Flash in their=20 > devices for the configuration memory. > Well, you are right, I am not familiar with Lattice and MicroSemi. From the= little I know about them their FPGA are modern in a sense that they a new = products and, may be, modern in specific system-level features, but when it= comes to size and performance of the fabric, including such important to s= ome of us characteristic as dynamic power per watt (static power is probabl= y o.k) they are at least 5 years behind X&A, but probably more than 5. >=20 > > DACs and SAR ADCs are also problem. Delta-sigma ADCs probably less so, = but I am not an expert. Anyway, for apps that I acre about SAR is more usef= ul than delta-sigma. >=20 > Once again you should tell that to MicroSemi... They make a mixed signal= =20 > FPGA with CPU, analog and FPGA on one die. I don't use it because of=20 > the price, a bit higher than I like to see. >=20 >=20 > > Due to all these factors small embedded solution based on Cortex-M inte= grated into FPGA is likely to and up more complex, using more chips and mor= e expensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA. >=20 > I think you are saying that an FPGA with internal MCU is not as useful=20 > as separate FPGA and MCU because the MCU will have lots of other stuff=20 > integrated that would be additional chips with the integrated approach. Yes, NOR flash, ADCs, DACs. =20 > Clearly it doesn't have to be that ways since at least one company=20 > makes such parts. >=20 >=20 > > The ugly part about MCU + FPGA solution is that, unlike chips from the = past, small modern Cortex-M MCUs rarely have good bus to talk to FPGA (goo= d=3Dsimple, not to slow and not too many pins). But then again, those old 3= 2-bit MCUs that had buses that I liked were in $25+ price range. For fair c= omparison I probably have to look at old 8-bitter that I never even tried t= o connect to FPGA. >=20 > That brings us back to the real differences between the MCU world and=20 > the typical FPGA world. MCUs are intended for apps where speed is=20 > limited by the software. FPGAs are intended for apps where speed is=20 > potentially much faster with the limitation potentially in the I/O. So= =20 > a typical high end FPGA will have lots of I/O and some very fast I/O. >=20 That about right, except that I am not talking about high-end FPGAs, but ab= out modern "low-cost" lines of A&X. So, fast I/O optional and very fast I/O= is rarely even an option (fast=3D1-3.125 Gbit/s, very fast=3D >3.125). But for MCU<->FPGA interface I will be mostly satisfied in much more modera= te speed. Say, something logically similar to venerable LPC bus, but withou= t 24-bit address space limit (28 bits probably acceptable) and with physica= l layer of RGMII. > But such an integrated MCU/FPGA device would not be intended for high=20 > end apps with Mbps I/O. The FPGA would be adding special functionality= =20 > that perhaps can't be done in the MCU alone. I had a design that=20 > required exactly this sort of need and ended up having to use an FPGA=20 > with an attached CODEC since there were no MCUs which could implement=20 > one interface. The FPGA was a bit jammed up in terms of capacity (only= =20 > 3 kLUT). A small soft core could do most of the work and potentially=20 > free up some space. Had a combined chip been available it would have=20 > been a breeze to implement the one interface in hardware (or maybe two)= =20 > and the rest of the design in software. >=20 >=20 > > Back to another reason why I think that hard ARM Cortex-M4 core in [Alt= era or Xilinx] FPGA does not look as a very good proposition: > > The added value of M3/M4 core alone, without flash and mixed-signal per= ipherals, is not that big. After all Nios2-f core (only core, without debug= support and avalon-mm infrastructure around it) occupies only ~25% of the = smallest Cyclone4 device or ~7% of the smallest Cyclone5-E and achieves com= parable performance. As far as I am concerned, the main advantage of Cortex= -M is a code density - significantly more code can fits on-chip. But even t= hat is less important if were are talking about Cyclone5 generation, becaus= e here the smallest member has 140 KB of embedded memory (not counting MLAB= s), which is often enough. >=20 > Yep, the low end MCU on an FPGA without any of the peripherals would not= =20 > be a lot more interesting than a soft core.=20 Just a nitpick - by definition there is no such thing as "MCU without any o= f the peripherals". Let's call them "MCU-style hard cores" or just "ARM Cor= tex-M4" because this particular core looks like the most logical (or least = illogical) candidate. > So when will they be doing=20 > a better job of the Vulcan mind meld and getting more analog on the FPGA= =20 > die? It's not like there is anything so special about FPGA logic that=20 > can't be done in analog compatible processes. Maybe you lose some=20 > density or performance, but that isn't what we are after. At least *I*= =20 > am looking for a system on chip which includes some FPGA fabric. Don't= =20 > think of it as an FPGA with an MCU on chip.=20 Yes, could be nice. But to be real useful FPGA part should not be too small= . I wouldn't bother for 1K 4-input LUTs. 5K looks like reasonable minimum, = at least for gray haired devs like you and me. Younger guys a spoiled, they= 'd want more than that. > Think of it as an MCU with=20 > FPGA fabric on chip just like the other umpty-nine peripherals they=20 > already have along with.... gasp!... 5 volt tolerance. lol > Is 5-V tolerance really that useful [in new designs] without ability to act= ually drive 5V outputs? I suppose, even you don't expect the later in 2015 = :-) > --=20 >=20 > Rick
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