SoC Builder
by Unknown on Jan 31, 2004 |
Not available! | ||
I think the SoC Builder project should happen. From discussions so far
(that I've seen), here's what I think should be done: First, I'll work on the generic netlist format, generic Synopsys library, and associated code. It's not super interesting work, but it's the only way I can think of to allow SoC builder to run legally on the OpenCores server. Second, it would be great if one of you web-guys out there (which I am not) would sign up for doing some initial web pages for us. Just some simple selection widgets and a way to spit out a text file of choices would be a good start. Of course, once you start, I suspect that we'll be asking for a lot more... For the first version of the SoC Builder, someone (possibly me) could just write some very simple scripts to glue together the structural netlist. Finally, there's the task of converting the generic SoC structural netlist to a specific target. I think this is the hardest part. My old OpenLPM project would be OK for doing this, but if we can get another language-neutral open-source module generation tool, I'd be for it. To improve performance for mapping to specific targets, I'll create an option for including target-specific gate-level netlists rather than the generic netlist. However, I want to be sure to have the generic version of each component as well so that the resulting designs can be re-targetted. Bill |
SoC Builder
by Unknown on Jan 31, 2004 |
Not available! | ||
I can do simple web design. I know html and Java. I can't do any php,perl,python or anything like that.
I would suggest starting this project on both the opencores website and sourceforge (linking with freshmeat wouldn't hurt either).
I also suggest searching for what other people are doing now for a few weeks to see what work has already been done. Maybe a componentized aproach would be good. One module for the GUI, serveral modules for different types of SOC builders (confluence, Perilog, netlist generator...), and modules for different automatic test bench generators.
Automatic test generation is very important. I know how to do great C testbenches with verilog and Icarus verilog simulator. I don't do VHDL though. I think you are going to find many people who are very picky about their HDL language, so a component approach would be better. That way, if they don't like your HDL choice, they can reuse your GUI and just build a different SOC builder module.
It would be great if we can find a GUI that would work good for us. The eclipse tools look nice and would be a good standard, but a lot of work. There are some better ones out there, I'm sure.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4178 bytes
Desc: not available
Url : http://www.opencores.org/forums.cgi/cores/attachments/20040131/6d70e3af/attachment.bin
|
SoC Builder
by Unknown on Jan 31, 2004 |
Not available! | ||
This would work great as a GUI:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/gef-home/overview.html?cvsroot=Tools_Project
It is eclipse based and there is a lot of momentum behind eclipse.
-Brian
-----Original Message-----
From: Brian Korsedal on behalf of Brian Korsedal
Sent: Sat 1/31/2004 10:05 AM
To: Discussion list about free open source IP cores
Cc:
Subject: RE: [oc] SoC Builder
I can do simple web design. I know html and Java. I can't do any php,perl,python or anything like that.
I would suggest starting this project on both the opencores website and sourceforge (linking with freshmeat wouldn't hurt either).
I also suggest searching for what other people are doing now for a few weeks to see what work has already been done. Maybe a componentized aproach would be good. One module for the GUI, serveral modules for different types of SOC builders (confluence, Perilog, netlist generator...), and modules for different automatic test bench generators.
Automatic test generation is very important. I know how to do great C testbenches with verilog and Icarus verilog simulator. I don't do VHDL though. I think you are going to find many people who are very picky about their HDL language, so a component approach would be better. That way, if they don't like your HDL choice, they can reuse your GUI and just build a different SOC builder module.
It would be great if we can find a GUI that would work good for us. The eclipse tools look nice and would be a good standard, but a lot of work. There are some better ones out there, I'm sure.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5186 bytes
Desc: not available
Url : http://www.opencores.org/forums.cgi/cores/attachments/20040131/8e894662/attachment.bin
|
SoC Builder
by Unknown on Feb 1, 2004 |
Not available! | ||
Brian Korsedal wrote:
I can do simple web design. I know html and Java. I can't do any php,perl,python or anything like that.
Great!
I would suggest starting this project on both the opencores website and sourceforge (linking with freshmeat wouldn't hurt either).
Ok. I just filed for an "SoC Builder" project on Source Forge. I'll also try to start an "SoC Builder" project on OpenCores as well in the "Other" category, like the SoC Interconnection project.
I also suggest searching for what other people are doing now for a few weeks to see what work has already been done. Maybe a componentized aproach would be good. One module for the GUI, serveral modules for different types of SOC builders (confluence, Perilog, netlist generator...), and modules for different automatic test bench generators.
I agree. Discussions about the component architecture should start as soon as a mail list can be created.
Automatic test generation is very important. I know how to do great C testbenches with verilog and Icarus verilog simulator. I don't do VHDL though. I think you are going to find many people who are very picky about their HDL language, so a component approach would be better. That way, if they don't like your HDL choice, they can reuse your GUI and just build a different SOC builder module.
Testbench generation seems like a tough nut to crack in a language neutral way. I agree that being component based makes sense, and plugging in new components should be easy. I think we should generate some C code that the on-chip processor can run to check out it's peripherals (and itself). This could be a simple script to combine C test routines, but the C code for each module would need to be written. This would work for any component attached to the CPU, whether Verilog, VHDL, or schematic based. I envision an SoC Builder system that can be used by non-RTL designers to customize parts. For example, I could choose a PIC or OpenRisc CPU, configure some SRAM and ROM, and get a gate-level netlist that could be sent to the fab. The web site could let me download an FPGA based emulation of my SoC which I could run on a custom emulator designed to act like the SoC. Hopefully, any new components that an RTL designer wants to add to his SoC should be easily added to our system. In that case, he's responsible for his own testbenches, and also for the C-code to check out his component. Such a product could compete in the microcontroller and DPS markets where users never see Verilog or VHDL. Such users would need support, custom emulators, compilers, etc. There may be room for small start-up companies here.
It would be great if we can find a GUI that would work good for us. The eclipse tools look nice and would be a good standard, but a lot of work. There are some better ones out there, I'm sure.
You clearly know a lot more about this end of the project than me. If there's no objections, I think you should make those decisions. To get started, I'd recommend doing something simple. I think each component should be able to have it's own web interface to customize it, which could start out as an html page with radio buttons, numeric fields, and check boxes to set values for the component. Selecting components could be a bit like a shopping cart, where each configured component shows up in a list that the user can edit. Of course, to a non-web programmer like me, this sounds simple, but I don't know the truth of it. We can also assume that each component is either directly connected to the CPU (memory, ROM, cache), or is on a bus (wishbone to start with). There should be C-code to exercise each from the CPU. Bill |
SoC Builder
by Unknown on Feb 1, 2004 |
Not available! | ||
I'll work on the GUI, but don't get your hopes up. I am really busy at work and I can sometimes be flakey. I've started a lot of projects before that have gone nowhere, but I know Java well and I've used eclipse. I think I can base the GUI on some eclipse code.
I want my user interface to be similar to Simulink or Kivio (Visio). However, instead of running things on the mathlab engine, the code will be run directly on a free simulator. This will be very slow, but cycle/bit accurate. In the distant future, I would like to work in a simple and fast way to simulate the design... in the distant future.
I think there should be a set of cores that are designed for testbenches. Things such as random data generators for DSP. File players just read in a golden file and read out the results somewhere and compare it against another file. FFT's (fftw C/C++ based, not HDL) to see the spectrum of what your DSP code is putting out. Maybe in the distant future, generic transmitters and recievers for protocols (DVB-T, 802.11a/b/g etc.). I know how to do the simple ones in a mix of verilog and C code.
Also, it would be great if the simulators would be started in a different thread and be able to run independent of the GUI. This way, you can start several simulations and come back the next day to see the results. Maybe there will be a browser window (like a file browser) for simulation threads where you can pause, analyze, halt and clean them up (their dump files).
At first I will stick to what I know and do everything just for Verilog code. I will make it flexible and modular. Each core that my GUI can use will need a small text file to tell the GUI what the core is and what it can do. Hopefully, this file would be a script. My GUI would provide generic commands and the script would translate them into exactly what needs to be done. These files should be small and easy to edit, less than a page. This way, each core can be whatever language it want's to be and my GUI will have a common interface to configure them. However, simulation will be difficult. Maybe we will have to convert everything to a netlist before we link them together for simulation? I don't know. It would be great to have a way to simulate mixed cores.
I think there will be five major HDL's for cores, Verilog, VHDL, netlist, confluence and SystemC. We will probably need someone who will work on the simulator because my GUI will just be eye candy unless it has one.
I probably won't get started on this right away, we are putting in 50 hour work weeks in my company trying to get our thingamagiger out the door. Probably in the beginning of March.
-Brian
-----Original Message-----
From: cores-bounces at opencores.org on behalf of Bill Cox
Sent: Sun 2/1/2004 3:41 AM
To: Discussion list about free open source IP cores
Cc:
Subject: Re: [oc] SoC Builder
Brian Korsedal wrote:
>I can do simple web design. I know html and Java. I can't do any php,perl,python or anything like that.
>
Great!
>I would suggest starting this project on both the opencores website and sourceforge (linking with freshmeat wouldn't hurt either).
>
>
Ok. I just filed for an "SoC Builder" project on Source Forge. I'll
also try to start an "SoC Builder" project on OpenCores as well in the
"Other" category, like the SoC Interconnection project.
>I also suggest searching for what other people are doing now for a few weeks to see what work has already been done. Maybe a componentized aproach would be good. One module for the GUI, serveral modules for different types of SOC builders (confluence, Perilog, netlist generator...), and modules for different automatic test bench generators.
>
>
I agree. Discussions about the component architecture should start as
soon as a mail list can be created.
>Automatic test generation is very important. I know how to do great C testbenches with verilog and Icarus verilog simulator. I don't do VHDL though. I think you are going to find many people who are very picky about their HDL language, so a component approach would be better. That way, if they don't like your HDL choice, they can reuse your GUI and just build a different SOC builder module.
>
>
Testbench generation seems like a tough nut to crack in a language
neutral way. I agree that being component based makes sense, and
plugging in new components should be easy. I think we should generate
some C code that the on-chip processor can run to check out it's
peripherals (and itself). This could be a simple script to combine C
test routines, but the C code for each module would need to be written.
This would work for any component attached to the CPU, whether Verilog,
VHDL, or schematic based.
I envision an SoC Builder system that can be used by non-RTL designers
to customize parts. For example, I could choose a PIC or OpenRisc CPU,
configure some SRAM and ROM, and get a gate-level netlist that could be
sent to the fab. The web site could let me download an FPGA based
emulation of my SoC which I could run on a custom emulator designed to
act like the SoC.
Hopefully, any new components that an RTL designer wants to add to his
SoC should be easily added to our system. In that case, he's
responsible for his own testbenches, and also for the C-code to check
out his component.
Such a product could compete in the microcontroller and DPS markets
where users never see Verilog or VHDL. Such users would need support,
custom emulators, compilers, etc. There may be room for small start-up
companies here.
>It would be great if we can find a GUI that would work good for us. The eclipse tools look nice and would be a good standard, but a lot of work. There are some better ones out there, I'm sure.
>
You clearly know a lot more about this end of the project than me. If
there's no objections, I think you should make those decisions.
To get started, I'd recommend doing something simple. I think each
component should be able to have it's own web interface to customize it,
which could start out as an html page with radio buttons, numeric
fields, and check boxes to set values for the component. Selecting
components could be a bit like a shopping cart, where each configured
component shows up in a list that the user can edit. Of course, to a
non-web programmer like me, this sounds simple, but I don't know the
truth of it.
We can also assume that each component is either directly connected to
the CPU (memory, ROM, cache), or is on a bus (wishbone to start with).
There should be C-code to exercise each from the CPU.
Bill
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 9182 bytes
Desc: not available
Url : http://www.opencores.org/forums.cgi/cores/attachments/20040201/b65070e0/attachment.bin
|
SoC Builder
by Unknown on Feb 5, 2004 |
Not available! | ||
About a business model: SoC Builder could do well along the lines of
viasic's method of single mask additions to a sea of cells that can make logic cores. SoC Builder (including icarus verilog and bus functional test models in icarus verilog) + viasic's and competitors's mask programmable logic could be a money maker if Bill's quest for the order flow to get the price right succeeds. The ante for first article needs to be below $15K for the kinds of customers I see as a freelance engineer. They are wanting something to sell fast, too. After doing some 5 or so work for hires like that, one garage shop engineer might spring for ownership of a mask programmable production Another way to make money might be custom logic and analog + cores that is reduced to solve only the problem at hand, for small volumes, in old processes on silicon, but I see most old process fabbing is way off in China...except for MEMS. Aligning with MEMS 10 micron processing ($120 mylar mask making!), is likely a way to make money, and that means analog, not just logic. It could soon mean non-silicon organic semiconductor processing also. That means testbenches that exist would work fine as is for clock referred tests, but all absolute time tests would need rewriting. For the "retarded" 10 micron silicon and the large feature size "but advanced..." and medium voltage, (15- 45V), organic transistor logic RTL code may be less valuable than a pared down wordwidth or handmade logic design that is well minimized. For these new developments multiple processors with special purposes and minimal/partial instructions and memory needs will be best. It will be a creative free-for-all if we make tools to do it. I think MEMS and organics will allow for "garage shop virtual chip companies" more than programmable logic alone, but programmable logic will be the bread and butter income generator to get anything started with. John Griessen Below is a review of parts of recent discussions I think are critical to this idea. ========================== To improve performance for mapping to specific targets, I'll create an option for including target-specific gate-level netlists [jg]Target specific HDL blocks and testbench blocks may be needed for truly weird processes -- If we keep the framework for generating these open, we will be able to deal with that at a source level, otherwise hand edited HDL blocks and testbench blocks will model the real (and slow), function of a short bus made from 45 volt organic semiconductors. ========================= trial version of SOPC-builder from an Alteras webpage --- shows that an SoC Builder can be done and has some merit. ========================= The market for these "virtual chip" companies (as I call them) could be huge. The major missing pieces are 1) advanced cheap silicon in low volume, and 2) easy configuration/selection of cores. OpenCores seems like a natural place to work on the second problem. I'm personally working hard on the first problem, and I'm going to nail it if I can get the resources to do it. Bill [jg]See MEMS/organics missing piece described above ================= -- Users post pre-synthesized cores to OpenCores (as well as RTL source), in a generic netlist format (this is something I know how to do). -- We write open-source tools that can combine those cores -- This tool then spits out gate level Verilog/VHDL On Wed, 2004-01-28 at 10:34, bporcella wrote:
don't see how impact on productivity could be potentially huge (or even
significant) -- (without a[jg]), testbench
[jg]Yes, the only hugely impactful productivity change would come from using modules pretested in a certain process to really check timing constraints so your additional parts on that bus would get timing checks. For a garage shop "virtual chip designer", his customer will fire him if he says "It's blown, lady... ya's Gonna' need a new engine...." ========================= A step in this direction is opencores coding guidelines manual and hopefully soon to follow a linter tool that will automatically enforce guidelines. regards, Damjan ======================= What's the business model? This is important, because without the prospect of money, progress on such a large project will be slooooooow. Stuart [jg]So true. -- John Griessen Cibolo Design Austin Texas EE good at IR systems, power supplies, logic design, A2D D2A, digital amps, mechatronics, SiGe and CMOS layout, MEMS/mech/electronic/photonic modeling, charge pump PV/battery/fuel cell power converters, linux counter #249315 |
SoC Builder
by Unknown on Feb 5, 2004 |
Not available! | ||
Hi, John.
I see that you're one of those out-of-the-box thinkers. I agree that
minimum chip orders need to be pushed down below $15K. I haven't been
thinking of MEMs or organics in particular, but these are interesting
ideas I'll have to keep in mind. Some of the other ideas you posted I
strongly agree with.
I think that an equation that could change the world is SoC Builder +
OpenCores + advanced ASICs for https://lists.sourceforge.net/lists/listinfo/socbuilder-discussion
This will let me take most of the SoC Builder related stuff off this
list, which is probably already annoying some people. If SoC Builder is
aproved on the OpenCores site, I'll ask to have the discussion list
hosted there.
Bill
John Griessen wrote:
About a business model: SoC Builder could do well along the lines of
viasic's method of single mask additions to a sea of cells that can make logic cores. SoC Builder (including icarus verilog and bus functional test models in icarus verilog) + viasic's and competitors's mask programmable logic could be a money maker if Bill's quest for the order flow to get the price right succeeds. The ante for first article needs to be below $15K for the kinds of customers I see as a freelance engineer. They are wanting something to sell fast, too. After doing some 5 or so work for hires like that, one garage shop engineer might spring for ownership of a mask programmable production Another way to make money might be custom logic and analog + cores that is reduced to solve only the problem at hand, for small volumes, in old processes on silicon, but I see most old process fabbing is way off in China...except for MEMS. Aligning with MEMS 10 micron processing ($120 mylar mask making!), is likely a way to make money, and that means analog, not just logic. It could soon mean non-silicon organic semiconductor processing also. That means testbenches that exist would work fine as is for clock referred tests, but all absolute time tests would need rewriting. For the "retarded" 10 micron silicon and the large feature size "but advanced..." and medium voltage, (15- 45V), organic transistor logic RTL code may be less valuable than a pared down wordwidth or handmade logic design that is well minimized. For these new developments multiple processors with special purposes and minimal/partial instructions and memory needs will be best. It will be a creative free-for-all if we make tools to do it. I think MEMS and organics will allow for "garage shop virtual chip companies" more than programmable logic alone, but programmable logic will be the bread and butter income generator to get anything started with. John Griessen Below is a review of parts of recent discussions I think are critical to this idea. ========================== To improve performance for mapping to specific targets, I'll create an option for including target-specific gate-level netlists [jg]Target specific HDL blocks and testbench blocks may be needed for truly weird processes -- If we keep the framework for generating these open, we will be able to deal with that at a source level, otherwise hand edited HDL blocks and testbench blocks will model the real (and slow), function of a short bus made from 45 volt organic semiconductors. ========================= trial version of SOPC-builder from an Alteras webpage --- shows that an SoC Builder can be done and has some merit. ========================= The market for these "virtual chip" companies (as I call them) could be huge. The major missing pieces are 1) advanced cheap silicon in low volume, and 2) easy configuration/selection of cores. OpenCores seems like a natural place to work on the second problem. I'm personally working hard on the first problem, and I'm going to nail it if I can get the resources to do it. Bill [jg]See MEMS/organics missing piece described above ================= -- Users post pre-synthesized cores to OpenCores (as well as RTL source), in a generic netlist format (this is something I know how to do). -- We write open-source tools that can combine those cores -- This tool then spits out gate level Verilog/VHDL On Wed, 2004-01-28 at 10:34, bporcella wrote:
don't see how impact on productivity could be potentially huge (or even
significant) -- (without a[jg]), testbench
[jg]Yes, the only hugely impactful productivity change would come from using modules pretested in a certain process to really check timing constraints so your additional parts on that bus would get timing checks. For a garage shop "virtual chip designer", his customer will fire him if he says "It's blown, lady... ya's Gonna' need a new engine...." ========================= A step in this direction is opencores coding guidelines manual and hopefully soon to follow a linter tool that will automatically enforce guidelines. regards, Damjan ======================= What's the business model? This is important, because without the prospect of money, progress on such a large project will be slooooooow. Stuart [jg]So true. |
SoC Builder
by Unknown on Feb 5, 2004 |
Not available! | ||
This will let me take most of the SoC Builder related stuff off this
Bill it takes about 5 minutes to register a new project and about 24 hrs to
set up a mailing list. I think SoC Builder would be an excellent way of
taking OpenCores idea to the next level and OpenCores would be happy to host
the SoC Builder project. :-)
In fact in Flextronics Semiconductor we have built a technology that does
the low level integration of IP Cores. It is similar to the idea of Perlilog
(which also started within Flextronics Semiconductor) and I'm talking to the
management to consider opening this technology and offer it as the low level
of the SoC Builder. This technology has already proved as several ASIC
projects within Flextronics Semiconductor were done using it. This lower
layer will integrate the IP cores together, generate a traffic cop (used
with WISHBONE type of IP Cores) and generate top level. It will instantiate
pads etc.
There was also a project started to build the GUI in Java (Marko do you have
a screenshot to publish?). I have attached a manual, a script that creates
an example SoC (OR1200, Ethernet MAC, PCI, UART, GPIO and Memory Controller)
and I'd like to hear your comments.
regards,
Damjan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Flint Toolkit Reference.rtf
Type: application/msword
Size: 517492 bytes
Desc: not available
Url : http://www.opencores.org/forums.cgi/cores/attachments/20040206/8f70caa6/FlintToolkitReference.wiz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marvin.fl
Type: application/octet-stream
Size: 26714 bytes
Desc: not available
Url : http://www.opencores.org/forums.cgi/cores/attachments/20040206/8f70caa6/marvin.obj
list, which is probably already annoying some people. If SoC Builder is aproved on the OpenCores site, I'll ask to have the discussion list hosted there. Bill |
SoC Builder
by Unknown on Feb 6, 2004 |
Not available! | ||
Bill Cox Wrote
I agree that minimum chip orders need to be pushed down below $15K.
Don't forget there's services like Mosys or Europractice (www.europractice.imec.be) that allow you to get prototypes and small volumes for reduced prices. Steven |
SoC Builder
by Unknown on Feb 6, 2004 |
Not available! | ||
Hi, Damjan.
Damjan Lampret wrote:
This will let me take most of the SoC Builder related stuff off this
list, which is probably already annoying some people. If SoC Builder is aproved on the OpenCores site, I'll ask to have the discussion list hosted there. Bill Bill it takes about 5 minutes to register a new project and about 24 hrs to set up a mailing list. I think SoC Builder would be an excellent way of taking OpenCores idea to the next level and OpenCores would be happy to host the SoC Builder project. :-) I certainly want to have this project hosted by OpenCores. I tried to register the project on Saturday or Sunday, but haven't gotten any response. Should I try again?
In fact in Flextronics Semiconductor we have built a technology that does
the low level integration of IP Cores. It is similar to the idea of Perlilog (which also started within Flextronics Semiconductor) and I'm talking to the management to consider opening this technology and offer it as the low level of the SoC Builder. This technology has already proved as several ASIC projects within Flextronics Semiconductor were done using it. This lower layer will integrate the IP cores together, generate a traffic cop (used with WISHBONE type of IP Cores) and generate top level. It will instantiate pads etc. That would be great. I had a long and not-so-friendly discussion with my own boss about this project. It's not easy for upper managagement to see why owning a proprietary SoC builder is less helpful than having a common community one. For ViASIC, I won the argument on cost. We can't afford to go it alone. For Flextronics, I would guess that FPGA conversions would be a good argument, since it's easier to convert FPGA designs to ASICs if they are built with open cores. I get the feeling that there are several large companies out there building proprietary SoC builders of their own, thinking that it will give them a competitve advantage. If your IBM, it's hard to argue against that, but for us smaller guys, we'd get crushed.
There was also a project started to build the GUI in Java (Marko do you have
a screenshot to publish?). I have attached a manual, a script that creates an example SoC (OR1200, Ethernet MAC, PCI, UART, GPIO and Memory Controller) and I'd like to hear your comments. regards, Damjan Wow! I noticed that the copyright says the manual is confidential. Is this a problem? Is it ok if I read it? Bill |
SoC Builder
by Unknown on Feb 6, 2004 |
Not available! | ||
Hi!
There was also a project started to build the GUI in Java (Marko do you
I've attached the screenshot, but it is really not something big, since we
engineers rather write the text code ;)
The code that way is much more reusable and configurable. We now have tons of
code in flint languge, able to generate cop, pads, BSDL files, etc.
Although Damjan sent you very bad example (but other ones are probably all
confidential), I hope you will find the code readable enough. I've also
attached added vi syntax highlighting file.
best regards,
Marko
-------------- next part --------------
" Vim syntax file
" Language: Flint
" Maintainer: Marko Mlinar, markom at flextronics.si
" Last Update: Wed Feb 19 10:05:54 CET 2003
" For version 5.x: Clear all syntax items
" For version 6.x: Quit when a syntax file was already loaded
if version = 600
setlocal iskeyword=@,48-57,_,192-255,+,-,?
else
set iskeyword=@,48-57,_,192-255,+,-,?
endif
" A bunch of useful Verilog keywords
syn keyword flintStatement include recursive exclude path
syn keyword flintStatement print function
syn keyword flintStatement return
syn keyword flintStatement catch foreach in if else
syn keyword flintStatement unconnected multidrive input output inout signal
syn match flintStatement ">>\?"
"old ones
syn keyword flintStatement project shell import toplevel abstract property pairwise add sub module
syn keyword flintTodo contained TODO
syn match flintOperator display contained "[&|~!)(*%@+/=?:;}{,.\^\-\[\]]"
syn match flintSpecial "\\[1-9]"
syn region flintRegex start=++ contains=flintRegexSpecial
syn match flintRegexCat "#"
syn match flintRegexRange "[0-9]\+[\t\n ]*[:][\t\n ]*[0-9]\+"
syn match flintRegexSpecial display contained "\\[1-9]"
syn region flintComment start="/\*" end="\*/" contains=flintTodo
syn match flintComment "//.*" oneline contains=flintTodo
syn match flintGlobal "$[a-zA-Z0-9_]\+\>"
syn match flintGlobal "${[^}]*}"
" syn match flintConstant "\"
syn match flintConstant "\"
syn match flintConstant "FLIN\-[0-9]\+"
" syn match flintNumber "\"
syn region flintString start="\"" skip=+\\\\\|\\"+ end="\"" contains=flintEscape,flintEscapeError
syn match flintEscape display contained "\\[nt\"\\]"
syn match flintEscapeError display contained "\\[^\"\\nt]"
syn cluster flintParenGroup contains=flintParen,flintBracket,flintParenError
"Modify the following as needed. The trade-off is performance versus
"functionality.
syn sync lines=50
" Define the default highlighting.
" For version 5.7 and earlier: only when not done already
" For version 5.8 and later: only when an item doesn't have highlighting yet
if version >= 508 || !exists("did_flint_syn_inits")
if version
else
command -nargs=+ HiLink hi def link
endif
" The default highlighting.
HiLink flintCharacter Character
HiLink flintString String
HiLink flintTodo Todo
HiLink flintComment Comment
HiLink flintConstant Constant
" HiLink flintNumber Number
HiLink flintOperator Operator
HiLink flintEscape Special
HiLink flintEscapeError flintError
HiLink flintSpecial Special
HiLink flintStatement Statement
HiLink flintGlobal Define
HiLink flintRegex Type
HiLink flintRegexCat Type
HiLink flintRegexRange Type
HiLink flintType Type
HiLink flintError Error
delcommand HiLink
endif
let b:current_syntax = "flint"
" vim: ts=8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flint_gui.png
Type: image/png
Size: 19412 bytes
Desc: not available
Url : http://www.opencores.org/forums.cgi/cores/attachments/20040206/11ca6b0c/flint_gui.png
have a screenshot to publish?). I have attached a manual, a script that creates an example SoC (OR1200, Ethernet MAC, PCI, UART, GPIO and Memory Controller) and I'd like to hear your comments. |
SoC Builder
by Unknown on Feb 6, 2004 |
Not available! | ||
Hi, Steven.
Redant Steven wrote:
Bill Cox Wrote
I agree that minimum chip orders need to be pushed down below $15K.
Don't forget there's services like Mosys or Europractice (www.europractice.imec.be) that allow you to get prototypes and small volumes for reduced prices. These services are wonderful. The chip they make are great for prototypes, but too expensive for production. I checked the published prices on the Mosis web site, and for their most advanced silicon, it comes out to over $1,000 US dollars per part, and the part is untested. I think for the average guy out there who just whats to make a million dollars, ASICs are no longer affordable. I want to change that. Bill |
SoC Builder
by Unknown on Feb 6, 2004 |
Not available! | ||
Dear Bill,
These services are wonderful. The chip they make are great for
prototypes, but too expensive for production. I checked the published prices on the Mosis web site, and for their most advanced silicon, it comes out to over $1,000 US dollars per part, and the part is untested. That depends on how many chips you want. You can go for small volumes (definition being: any volume the foundry doesn't want to give to you) too. This can be up to a million pieces of a rather small chip e.g. Hence there are some extra questions: What technology have you calculated with? How many parts? Only a protoype run that gives you a very limited amount of parts?
I think for the average guy out there who just whats to make a million
Well, that depends. It's not necessary to use the most advanced technologies to make an application that will make you a million bucks. If you stay in the 'bigger' technologies ASICS are very affordable still. If you want to use e.g. .13 it's another story.
Testing setup (SW/HW) cost is also amortized over the amount of chips you want to make.
I would be very pleased to hear about novel ideas to get the cost of ASICs down for smaller volumes!
Steven
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores
dollars, ASICs are no longer affordable. I want to change that. |
SoC Builder
by Unknown on Feb 6, 2004 |
Not available! | ||
Your project was approved.. Just log in to opencores web and check your
personal page.. regards, Miha On Friday 06 February 2004 12:41 pm, Bill Cox wrote:
I certainly want to have this project hosted by OpenCores. I tried to
register the project on Saturday or Sunday, but haven't gotten any response. Should I try again? |
SoC Builder
by Unknown on Feb 7, 2004 |
Not available! | ||
I certainly want to have this project hosted by OpenCores. I tried to
register the project on Saturday or Sunday, but haven't gotten any response. Should I try again? Did you managed to have it registered? Did you get a mailing list? Let me know if you have any problems.
That would be great. I had a long and not-so-friendly discussion with
my own boss about this project. It's not easy for upper managagement to see why owning a proprietary SoC builder is less helpful than having a common community one. For ViASIC, I won the argument on cost. We can't afford to go it alone. For Flextronics, I would guess that FPGA conversions would be a good argument, since it's easier to convert FPGA designs to ASICs if they are built with open cores. I get the feeling that there are several large companies out there building proprietary SoC builders of their own, thinking that it will give them a competitve advantage. If your IBM, it's hard to argue against that, but for us smaller guys, we'd get crushed. True. Flextronics is one of the major FPGA to ASIC conversion vendors and for conversion open source means easy to handle. However Flextronics also does SOCs (RTL-to-GDS flow). In this case the situation gets a little different. However Flextronics is very open minded and believes you need to be on the bleeding edge of changes or you will be run over by competition. I think open source has an excellent future also in hardware (to be more specific in cores and SoCs). IBM is now embracing Linux after many decades of pushing proprietary software. I think IBM in ten years will be doign the same with hardware intellectual property (cores and SoCs).
Wow! I noticed that the copyright says the manual is confidential. Is
I have attached a more apropriate version. FLINT as a whole is still
proprietary, but copy of the manual you can read it and if majority thinks
this could be good underlaying technology for the SoC Builder, then I will
talk to Flex management.
regards,
Damjan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Flint Toolkit Reference.rtf
Type: application/msword
Size: 503688 bytes
Desc: not available
Url : http://www.opencores.org/forums.cgi/cores/attachments/20040207/9908bd08/FlintToolkitReference.wiz
this a problem? Is it ok if I read it? |