Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Thursday, March 21, 2019 at 5:40:30 AM UTC-4, Tom Gardner wrote: > On 21/03/19 02:21, gnuarm.deletethisbit@gmail.com wrote: > > On Wednesday, March 20, 2019 at 5:38:16 PM UTC-4, David Brown wrote: > >> > >> I agree that software should not in itself create a problem. Trying to > >> think of them as "logic" /would/ create problems. Think of them as > >> software, and program them as software. I expect you'd think of them as > >> entirely independent units with independent programs, rather than as a > >> multi-cpu or heterogeneous system. > > > > Ok, please tell me what those problems would be. I have no idea what you > > mean by what you say. You are likely reading a lot into this that I am not > > intending. > > I have no difficulty understanding what he is saying. > > Several people have difficulty understanding what you > are proposing. > > You are proposing vague ideas, so the onus is on you > to make your ideas clear. There is no onus. This is not a business proposal. If you want to discuss it, do so. If not, don't. If you can't tell me what your concerns are, I can't address them. If no one can tell me what problems are being talked about by "Trying to think of them as "logic" /would/ create problems." I can't possibly address those concerns. > >>> As to the connection, I really don't get your point. They either connect > >>> directly to the hardware because that's how they are designed, or they > >>> don't... because that's how they are designed. I don't know what you are > >>> saying about that. > >>> > >> > >> "Synchronise directly with hardware" might be a better phrase. > > > > I don't know why and likely I'm' not going to care. I think you need to > > learn more of how the F18A works. > > No, we really don't have to learn more about one specific > processor - especially if it is just to help you. > > If, OTOH, you succinctly summarise its key points and > how that achieves benefits, then we might be interested. I don't see a question. Are you trying to teach me how to post in newsgroups? lol Ask a question if you have one. Explain something I've said that is wrong. But if you don't have anything better to say, I can't help you. > >>> Enough! The CPUs run software. Now, what is YOUR point? > >>> > >> > >> My point was that these are not logic, they are not logic elements (even if > >> they could be physically small and cheap and scattered around a chip like > >> logic elements). Thinking about them as "sequential logic elements" is not > >> helpful. Think of them as small processors running simple and limited > >> /software/. Unless you can find a way to automatically generate code for > >> them, then they will be programmed using a /software/ programming language, > >> not a logic or hardware programming language. If you are happy to accept > >> that now, then great - we can move on. > > > > You have it backwards. Please show me what you think the problems are. I > > don't care if they run software or have a Maxwell demon tossing bits about as > > long as it does what I need. You seem to get hung up on terminology so > > easily. > > You need to explain your points better. > > There's the old adage that "you only realise how little > you know about a subject when you try to teach it to > other people". Which points? I'm starting to think you are not here for the hunting. > > That is your construct because you know nothing of how the F18A works. As > > I've mentioned before, you would do well to read some of the app notes on > > this device. It really does have some good ideas to offer. > > Give us the elevator pitch, so we can estimate whether > it would be a beneficial use of our remaining life. If you don't have any idea what I'm talking about at this point, an elevator pitch won't help. > > The point wasn't that I don't have a business plan. The point was that I > > haven't given this as much thought as would have been done if I were working > > on a business plan. I'm kicking around an idea. I'm not in a position to > > create FPGA with or without small CPUs. > > > > > >> Give me a /reason/ to all this - rather than just saying you can make a > >> simple stack-based cpu that's very small, so you could have lots of them on > >> a chip. > > > > Why? Why don't you give ME a reason? Why don't you switch your point of > > view and figure out how this would be useful? Neither of us have anything to > > gain or lose. > > Why? Because you are trying to propagate your ideas. > The onus is on you to convince us, not the other way > around. No, I'm trying to discuss an idea. If you don't wish to discuss the idea, then that's fine. Rick C.Article: 161276
On Thursday, March 21, 2019 at 6:49:11 AM UTC-4, Theo wrote: > gnuarm.deletethisbit@gmail.com wrote: > > On Wednesday, March 20, 2019 at 6:53:07 AM UTC-4, Theo wrote: > > > Your bottom-up approach means it's difficult to see the big picture o= f > > > what's going on. That means it's hard to understand the whole system= , and > > > to program from a whole-system perspective. > >=20 > > I never mentioned a bottom up or a top down approach to design. Nothin= g > > about using these small CPUs is about the design "direction". I am pre= tty > > sure that you have to define the circuit they will work in before you c= an > > start designing the code. >=20 > Your approach is 'I have this low-level thing (a tiny CPU), what can I us= e > it for?'. That's bottom up. A top down view would be 'my problem is X, > what's the best way to solve it?'. The advantage of the latter view is y= ou > can explore some of the architectural space before targeting a solution > that's appropriate to the problem (with metrics to measure it), aiming to > find the global maximum. In a bottom-up approach you need to sell to use= rs > that your idea will help their problem, but until you build a system they > don't know that it will even be a local maximum. I'm not designing anything so I can't be designing bottom up. I'm not sell= ing anything, so I don't have users. =20 I'm discussing an idea. I'm kicking a can. I'm running a flag up the flag= pole.=20 If you aren't interested in discussing this, then that's ok. But there's n= o point at all in having a meta-discussion.=20 > > > What's the logic equation of a processor? =20 > >=20 > > Obviously it is like a combination of LUTs with FFs and able to impleme= nt > > any logic you wish including math. BTW, in many devices the elements a= re > > not at all so simple. Xilinx LUTs can be used as shift registers. The= re > > are additional logic within the logic blocks that allow math with carry > > chains, combining LUTs to form larger LUTs, breaking LUTs into smaller > > LUTs and lets not forget about routing which may not be used much anymo= re, > > not sure. >=20 > You can still reason about blocks as combinations of basic functions. A > block that is LUT+FF can still be analysed in separate parts. > A processor is a 'black box' as far as the tools go. That means any > software is opaque to analysis of correctness. The tools therefore can't > know that the circuit they produced matches the input HDL. "Correctness" in what sense? I've never worked with tools that could analy= ze my HDL to tell me if it was logically correct. I really have no idea wh= at you are talking about here. I also don't see the point of your pointing= out the LUT can be separate from the FF in a LUT/FF combination. You can = model the CPU as a large LUT with FFs. It can do the same job. The FF can= be removed. The logic can be removed. Whatever analysis that can be done= on the LUT/FF can be applied to the CPU. =20 If you want to verify the "correctness" of parts of a design my inspection,= I would expect that to be done on the HDL anyway, not on the generated log= ic... unless you thought the tools were suspect.=20 > Simulation does not give you equivalence checking of the form of LVS (lay= out > versus schematic) or compiler correctness testing, it only tests a > particular set of (usually hand-defined) test cases. There's much less > coverage than equivalence checking tools. So those techniques can't be applied to software? =20 > > Why does it need to be inferred. If you want to write an HDL tool to t= urn > > HDL into processor code, have at it. But then there are other methods.= =20 > > Someone mentioned his MO is to use other tools for designing his > > algorithms and letting that tool generate the software for a processor = or > > the HDL for an FPGA. That would seem easy enough to integrate. >=20 > That's roughly what OpenCL and friends can do. But those are top-down > architecturally (starting with a chip block diagram), rather than startin= g > with tiny building blocks as you're suggesting. >=20 > > Huh? You can't simulate code on a processor??? >=20 > Verification is greater than simulation, as described above. >=20 > > > If we scale the processors up a bit, I could see the merits in say a > > > bank of, say, 32 Cortex M0s that could be interconnected as part of t= he > > > FPGA fabric and programmed in software for dedicated tasks (for > > > instance, read the I2C EEPROM on the DRAM DIMM and configure the DRAM > > > controller at boot). > >=20 > > I don't follow your logic. What is different about the ARM processor f= rom > > the stack processor other than that it is larger and slower and require= s a > > royalty on each one? Are you talking about writing the code in C vs.= =20 > > what ever is used for the stack processor? >=20 > If you have an existing codebase (supplied by the vendor of your external > chip, for example), it'll likely be in C. It won't be in > special-stack-assembler, and your architecture seems to be designed to no= t > be amenable to compilers. You can write any compiler you want. I don't know what libraries you would= be using to replace FPGA logic with software. Are we talking about print = statements? =20 How do you port C libraries to logic in an FPGA now? Do it the same way.= =20 > > The point of the many hard cores is the saving of resources. Soft core= s > > would be the most wasteful way to implement logic. If the application = is > > large enough they can implement things in software that aren't as > > practical in HDL, but that would be a different class of logic from the > > tiny CPUs I'm talking about. >=20 > 'Wastefulness' is one parameter. But you can also consider that every > unused hard-core is also wasteful in terms of silicon area. Can you show > that the hard-cores would be used enough of the time to outweigh the spac= e > they waste on other people's designs? That assumes some number of CPUs on the FPGA. We don't have those numbers.= We also don't have any real data on how large a logic block is in an FPGA= , at least I don't. y I think you are making silly points when we are discussing a concept. Of c= ourse we won't have the sort of data you are talking about.=20 > > You lost me with the gear shift. The mention of instruction rate is ab= out > > the CPU being fast enough to keep up with FPGA logic. The issue with > > "heterogeneous performance" is the "heterogeneous" part, lumping the ma= ny > > CPUs together to create some sort of number cruncher. That's not what > > this is about. Like in the GA144, I fully expect most CPUs to be sitti= ng > > around most of the time idling, waiting for data. This is a good thing > > actually. These CPUs could consume significant current if they run at = GHz > > all the time. I believe in the GA144 at that slower rate each processo= r > > can use around 2.5 mA. Not sure if a smaller process would use more or > > less power when running flat out. It's been too many years since I wor= ked > > with those sorts of numbers. >=20 > OK, so once we drop any idea of MIPS, we're talking about something simpl= er > than a Cortex M0. You should be able to make a design that clocks at a f= ew > hundred MHz on an FPGA process. =20 I don't think a few hundred MIPS is fast enough to actually be useful. GIP= S is required. =20 > You could choose to run it synchronously > with your FPGA logic, or on an internal clock and synchronise inputs and > outputs. You probably wouldn't tile these, but you could deploy them as = a > 'hardware thread' in places you need a complicated state machine. A state machine is one application. But I don't see them being limited in = any way in replacing logic other than logic that is too small for this to b= e efficient.=20 Xilinx makes a big deal of their shift registers from a LUT. I've seen des= igns where many stages of shift register were needed. This CPU could repla= ce a large number of those running at some hundreds of MHz data clock rate.= =20 > > > In essence, your proposal has a disconnect between the situations exi= sting > > > FPGA blocks are used (implemented automatically by P&R tools) and the > > > situations software is currently used (human-driven software and > > > architectural design). It's unclear how you claim to bridge this gap= . > >=20 > > I certainly don't see how P&R tools would be a problem. They accommoda= te > > multipliers, DSP blocks, memory block and many, many special bits of > > assorted components inside the FPGAs which vary from vendor to vendor.= =20 > > Clock generators and distribution is pretty unique to each manufacturer= .=20 > > Lattice has all sorts of modules to offer like I2C and embedded Flash.= =20 > > Then there are entire CPUs embedded in FPGAs. Why would supporting the= m > > be so different from what I am talking about? >=20 > If this is a module that the tools have no visibility over, ie just a blo= b > with inputs and outputs, then they can implement that. =20 Why no visibility?=20 > In that instance > there is a manageability problem - beyond a handful of processes, writing > heterogeneous distributed software is hard. Unless each processor is doi= ng > a very small, well-defined, task, I think the chances of bugs are high. You need to explain to me what is hard about *this*. Giving it a label and= then saying anything with that label is hard doesn't mean much. I don't t= hink the label fits.=20 > If instead you want interaction with the toolchain in terms of > generating/checking the software running on such cores, that's also > problematic. I don't follow. In the design it's logic. You keep trying to think of it = the way you think of all software. It's logic. Inputs and outputs. You o= nly need to dig into the code after you find there is something wrong with = the mapping of inputs to outputs like any other logic module. Presumably t= he code would have been simulated with appropriate inputs and outputs.=20 > I hadn't seen Picoblaze before, but that seems a strong fit with what you= 're > suggesting. So a question: why isn't it more successful? And why isn't > Xilinx putting hard Picoblazes into their FPGAs, which they could do > tomorrow if they felt the need? More successful than what? The Volkswagen Beetle? =20 I can't explain much of what Xilinx does except they respond to their large= st customers who pay thousands of dollars for a single FPGA chip. They say= what goes into Xilinx FPGAs and the rest of us are tag-alongs. Literally.= =20 Rick C.Article: 161277
On Thursday, March 21, 2019 at 7:48:17 AM UTC-4, Tom Gardner wrote: > > That attitude surprises me, since all my /designs/ have been > based on "what do I need to achieve" plus "what can individual > technologies achieve" plus "which combination of technologies > is best at achieving my objectives". I.e top down with a > knowledge of the bottom pieces. I'm not designing anything at the moment. I'm trying to discuss an idea. Have you never brain stormed techniques and methods? Rick C.Article: 161278
On 21/03/19 14:57, gnuarm.deletethisbit@gmail.com wrote: > On Thursday, March 21, 2019 at 7:48:17 AM UTC-4, Tom Gardner wrote: >> >> That attitude surprises me, since all my /designs/ have been based on "what >> do I need to achieve" plus "what can individual technologies achieve" plus >> "which combination of technologies is best at achieving my objectives". I.e >> top down with a knowledge of the bottom pieces. > > I'm not designing anything at the moment. I'm trying to discuss an idea. > Have you never brain stormed techniques and methods? Many many times, professionally often in formal settings. Generating ideas is relatively easy. Refining an idea and defining it in sufficient detail that it can be assessed is a more difficult task. Very few ideas survive. It is /always/ up to the "champion" (of an idea or product) to be able to convincingly explain the advantages and acknowledge the disadvantages.Article: 161279
On Thursday, March 21, 2019 at 11:58:54 AM UTC-4, Tom Gardner wrote: > On 21/03/19 14:57, gnuarm.deletethisbit@gmail.com wrote: > > On Thursday, March 21, 2019 at 7:48:17 AM UTC-4, Tom Gardner wrote: > >> > >> That attitude surprises me, since all my /designs/ have been based on "what > >> do I need to achieve" plus "what can individual technologies achieve" plus > >> "which combination of technologies is best at achieving my objectives". I.e > >> top down with a knowledge of the bottom pieces. > > > > I'm not designing anything at the moment. I'm trying to discuss an idea. > > Have you never brain stormed techniques and methods? > > Many many times, professionally often in formal settings. > > Generating ideas is relatively easy. > > Refining an idea and defining it in sufficient detail that > it can be assessed is a more difficult task. Very few ideas > survive. > > It is /always/ up to the "champion" (of an idea or product) > to be able to convincingly explain the advantages and > acknowledge the disadvantages. So I guess we need to find a champion. Rick C.Article: 161280
It's been about 3 years since I've done any *serious* FPGA work. I used mostly VHDL or sometimes my own Matlab scripts to create automated VHDL files. I would like to know if anyone has used High-level synthesis recetnly for *real* work and if so, would they recommend that people learn it?Article: 161281
On 3/21/19 11:40 AM, Benjamin Couillard wrote: > It's been about 3 years since I've done any *serious* FPGA work. I used mostly VHDL or sometimes my own Matlab scripts to create automated VHDL files. > > I would like to know if anyone has used High-level synthesis recetnly for *real* work and if so, would they recommend that people learn it? > I definitely actively do *serious* FPGA work. I use VHDL, I testbench in VHDL, and every time I see the FPGA companies try to push me into high-level synthesis I can't quite see what the point is. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 161282
Benjamin Couillard <benjamin.couillard@gmail.com> wrote: > It's been about 3 years since I've done any *serious* FPGA work. I used > mostly VHDL or sometimes my own Matlab scripts to create automated VHDL > files. > > I would like to know if anyone has used High-level synthesis recetnly for > *real* work and if so, would they recommend that people learn it? I think it depends a lot on your application area. If what you do is DSP-style compute, you might be able to use HLS. It might save writing some VHDL, although if you're good at writing VHDL there might not be much in it. If your problem doesn't look much like DSP, I think it'll be more difficult to bend HLS to your will. Theo (my problems rarely look like DSP, so I don't use it)Article: 161283
In article <1f6821b7-29e5-4c99-813f-74a4577a75e9@googlegroups.com>, Benjamin Couillard <benjamin.couillard@gmail.com> wrote: >It's been about 3 years since I've done any *serious* FPGA work. I used mostly VHDL or sometimes my own Matlab scripts to create automated VHDL files. > >I would like to know if anyone has used High-level synthesis recetnly for *real* work and if so, would they recommend that people learn it? Like the other posters - I user Verilog and SystemVerilog. HLS is still niche, with few good use-cases - contrary to how much the industry is still struggling to define it as the next big thing in EDA. I've written elsewhere - the problem with today's HLS solutions is the language choice, and target audience. Currently, that's C, and C like languages, targetting software folks. Both are the wrong choices. If the industry ever get's around to creating an HLS synthesis solution for code written in SystemVerilog - targetting the hardware designer - then I'll be the first in line. Until then it'll remain a niche solution - no matter how many new emails flood my inbox indicating it's the newest, bestest thing... Regards, MarkArticle: 161284
Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
> It's been about 3 years since I've done any *serious* FPGA work. I used mostly VHDL or sometimes my own Matlab scripts to create automated VHDL files.
>
> I would like to know if anyone has used High-level synthesis recetnly for *real* work and if so, would they recommend that people learn it?
>
>
>
We are working on a system where we connect an FPGA and a CPU.
The FPGA will implement almost 20-30 peripherals.
The CPU will run Linux, and will need a driver for each type
of peripheral.
The Linux driver for each peripheral type will contain a main header
file, and a file describing the user interface (I.E: the peripheral
registers)
A register could look like:
typedef struct uart_mode_s {
uint32_t bits:4;
uint32_t parity:1;
uint32_t odd:1;
uint32_t encoding:2;
uint32_t baud:24;
} uart_mode_t;
I use the register header file as input to a Python program to generate
the register in VHDL. The Python program will generate a package
containing the register with a std_logic_vector, and functions which
will convert to and from a "record" so I can use the high level view
of the register in VHDL.
If I change the C header file in the driver, then the VHDL code will
also change, due to dependencies in the build.
Plan to have another Python program which will take a CSV
file and use the contents to instantiate peripherals, and
to generate the interface to the processor, including the address
decoding. (Perhaps a JSON file will be better, though)
This allows me to adopt to changing requirements and save a lot of time
as well as keeping the driver and the peripheral in sync.
I know others that do it the same way.
AP
Article: 161285A.P.Richelieu <aprichelieu@gmail.com> wrote: > I use the register header file as input to a Python program to generate > the register in VHDL. The Python program will generate a package > containing the register with a std_logic_vector, and functions which > will convert to and from a "record" so I can use the high level view > of the register in VHDL. That sounds more like what others call a 'Hardware Construction Language', rather than HLS. In your case, it sounds like you're doing basic 1:1 transformations - C structure to a bundle of wires, Python declaration to VHDL declaration, etc. You're writing Python not VHDL but you're still thinking like a hardware designer. That's not un-useful, but HLS is different in that the tool decides where the state should go - you describe your algorithm in (say) C or Matlab, and the tool decides to build a state machine from your declaration, but there are a large number of semantic transformations it goes through (for instance, unrolling loops and turning them into pipelined parallel hardware). The state in the output circuit bares only a passing resemblance to the state defined in the input C code. HLS has a much larger semantic gap to cross than a hardware construction language, which is why it doesn't work very well (IMHO). TheoArticle: 161286
Le jeudi 21 mars 2019 15:56:02 UTC-4, Theo Markettos a =C3=A9crit=C2=A0: > Benjamin Couillard <benjamin.couillard@gmail.com> wrote: > > It's been about 3 years since I've done any *serious* FPGA work. I used > > mostly VHDL or sometimes my own Matlab scripts to create automated VHDL > > files. > >=20 > > I would like to know if anyone has used High-level synthesis recetnly f= or > > *real* work and if so, would they recommend that people learn it? >=20 > I think it depends a lot on your application area. >=20 > If what you do is DSP-style compute, you might be able to use HLS. It mi= ght > save writing some VHDL, although if you're good at writing VHDL there mig= ht > not be much in it. >=20 > If your problem doesn't look much like DSP, I think it'll be more difficu= lt > to bend HLS to your will. >=20 > Theo >=20 > (my problems rarely look like DSP, so I don't use it) For DSP I created my own Matlab scripts to create automated VHDL files (fil= ters or ROMs). I worked great but was only semi-portable. I.e. it needed so= me degree of customization for each application.Article: 161287
On 3/21/19 9:37 PM, A.P.Richelieu wrote:
> Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
>> It's been about 3 years since I've done any *serious* FPGA work. I
>> used mostly VHDL or sometimes my own Matlab scripts to create
>> automated VHDL files.
>>
>> I would like to know if anyone has used High-level synthesis recetnly
>> for *real* work and if so, would they recommend that people learn it?
>>
>>
>>
>
> We are working on a system where we connect an FPGA and a CPU.
> The FPGA will implement almost 20-30 peripherals.
> The CPU will run Linux, and will need a driver for each type
> of peripheral.
>
> The Linux driver for each peripheral type will contain a main header
> file, and a file describing the user interface (I.E: the peripheral
> registers)
>
> A register could look like:
>
> typedef struct uart_mode_s {
> uint32_t bits:4;
> uint32_t parity:1;
> uint32_t odd:1;
> uint32_t encoding:2;
> uint32_t baud:24;
> } uart_mode_t;
>
> I use the register header file as input to a Python program to generate
> the register in VHDL. The Python program will generate a package
> containing the register with a std_logic_vector, and functions which
> will convert to and from a "record" so I can use the high level view
> of the register in VHDL.
>
> If I change the C header file in the driver, then the VHDL code will
> also change, due to dependencies in the build.
>
> Plan to have another Python program which will take a CSV
> file and use the contents to instantiate peripherals, and
> to generate the interface to the processor, including the address
> decoding. (Perhaps a JSON file will be better, though)
>
> This allows me to adopt to changing requirements and save a lot of time
> as well as keeping the driver and the peripheral in sync.
>
> I know others that do it the same way.
>
> AP
If you haven't gotten too deep into writing your own code yet, you may
want to check out a project I've been working on sporadically for a
while now. https://github.com/NJDFan/register-maps
There's also a more standard format for describing registers, IP-XACT,
which like mine is XML-based. I found it impossibly obtuse to work
with, but note it for the record.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
Article: 161288In article <q731fb$lbr$1@dont-email.me>, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote: >If you haven't gotten too deep into writing your own code yet, you may >want to check out a project I've been working on sporadically for a >while now. https://github.com/NJDFan/register-maps > >There's also a more standard format for describing registers, IP-XACT, >which like mine is XML-based. I found it impossibly obtuse to work >with, but note it for the record. IP-XACT is a solution looking for a problem. It's actually quite horrible, and a bad idea. From the camp of people who think "XML solves everything, more XML must be better..." Regarding the register-maps and autogeneration of RTL code, etc. We did that 10 years ago or so - but moved on to doing the opposite. We encode all the register information - offsets, masks, bit-field definitions, descriptions, etc directly in our code - NOT META COMMENTS - but SystemVerilog RTL code itself. We have catalog logic that checks for validity (overlaps, etc...), and other rules. A quick simulation job is run to generate (all sourced from the RTL) 1. Documentation (various formats - txt files, .csv) 2. Header files (*.h, .json, etc..) 3. other meta-data There's also simulation hooks included to look up address by name, etc, that ties right into the testbench setup. Works a charm. Machine generate RTL code always was ugly. Meta comment parsing was futzy. Now, it's the best of both worlds. Regards, MarkArticle: 161289
Le vendredi 22 mars 2019 13:40:58 UTC-4, gtwrek a =C3=A9crit=C2=A0: > In article <q731fb$lbr$1@dont-email.me>, > Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote: > >If you haven't gotten too deep into writing your own code yet, you may= =20 > >want to check out a project I've been working on sporadically for a=20 > >while now. https://github.com/NJDFan/register-maps > > > >There's also a more standard format for describing registers, IP-XACT,= =20 > >which like mine is XML-based. I found it impossibly obtuse to work=20 > >with, but note it for the record. >=20 > IP-XACT is a solution looking for a problem. It's actually quite > horrible, and a bad idea. From the camp of people who think "XML solves > everything, more XML must be better..." >=20 > Regarding the register-maps and autogeneration of RTL code, etc. > We did that 10 years ago or so - but moved on to doing the opposite. > We encode all the register information - offsets, masks, bit-field > definitions, descriptions, etc directly in our code - NOT META COMMENTS - > but SystemVerilog RTL code itself. We have catalog logic that checks=20 > for validity (overlaps, etc...), and other rules. A quick simulation > job is run to generate (all sourced from the RTL) > 1. Documentation (various formats - txt files, .csv) > 2. Header files (*.h, .json, etc..) > 3. other meta-data >=20 > There's also simulation hooks included to look up address by name, etc, > that ties right into the testbench setup. >=20 > Works a charm. Machine generate RTL code always was ugly. Meta > comment parsing was futzy. Now, it's the best of both worlds. >=20 > Regards, >=20 > Mark I did the same in VHDL about 10 years ago. It worked well for a medium-size= d system. It was based on a code snippet posted by Jonathan Bromley on comp= .lang.vhdlArticle: 161290
Den 2019-03-22 kl. 17:11, skrev Rob Gaddi:
> On 3/21/19 9:37 PM, A.P.Richelieu wrote:
>> Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
>>> It's been about 3 years since I've done any *serious* FPGA work. I
>>> used mostly VHDL or sometimes my own Matlab scripts to create
>>> automated VHDL files.
>>>
>>> I would like to know if anyone has used High-level synthesis recetnly
>>> for *real* work and if so, would they recommend that people learn it?
>>>
>>>
>>>
>>
>> We are working on a system where we connect an FPGA and a CPU.
>> The FPGA will implement almost 20-30 peripherals.
>> The CPU will run Linux, and will need a driver for each type
>> of peripheral.
>>
>> The Linux driver for each peripheral type will contain a main header
>> file, and a file describing the user interface (I.E: the peripheral
>> registers)
>>
>> A register could look like:
>>
>> typedef struct uart_mode_s {
>> uint32_t bits:4;
>> uint32_t parity:1;
>> uint32_t odd:1;
>> uint32_t encoding:2;
>> uint32_t baud:24;
>> } uart_mode_t;
>>
>> I use the register header file as input to a Python program to
>> generate the register in VHDL. The Python program will generate a package
>> containing the register with a std_logic_vector, and functions which
>> will convert to and from a "record" so I can use the high level view
>> of the register in VHDL.
>>
>> If I change the C header file in the driver, then the VHDL code will
>> also change, due to dependencies in the build.
>>
>> Plan to have another Python program which will take a CSV
>> file and use the contents to instantiate peripherals, and
>> to generate the interface to the processor, including the address
>> decoding. (Perhaps a JSON file will be better, though)
>>
>> This allows me to adopt to changing requirements and save a lot of time
>> as well as keeping the driver and the peripheral in sync.
>>
>> I know others that do it the same way.
>>
>> AP
>
> If you haven't gotten too deep into writing your own code yet, you may
> want to check out a project I've been working on sporadically for a
> while now. https://github.com/NJDFan/register-maps
>
> There's also a more standard format for describing registers, IP-XACT,
> which like mine is XML-based. I found it impossibly obtuse to work
> with, but note it for the record.
>
Thank You,
I will have a look.
I was discussing this with the guy that has generated the FPGA
code for my current project, and he suggested an XML based
approach instead of C.
If I was going that route, to start from a description and
generate both C and VHDL, I would probably use a JSON format,
since they are so much easier to read.
In my mind the best way is to start off with the C driver.
If you like us are running Linux & U-Boot, then you
have an API for the driver, which needs to be followed.
The H/W implementation of all the peripherals I have seen basically
suck, and the C driver implementer has to overcome all the deficiencies
forced upon him/her by the chip designers.
The proper approach is to start with the API and then
figure out how to implement this in a driver in the most efficient way.
spi_xfer(peripheral SPI, uint8_t src, size_t size, enum spi_flags flags)
{
SPI->START = flags; // Activate CS on request
strncpy(SPI->FIFO, src, size);
SPI->STOP = flags; // Deactivate CS on request
}
Once I have the driver figured out, I already have the headers,
so I do not want to create XML to regenerate what I already have.
AP
Article: 161291I wouldn't recommend pursuing HLS. It's a siren call. It will just bring you trouble. My rule is this: when I feel like the tools have successfully mastered mid-level synthesis, I'll give HLS another look. One who cannot yet crawl cannot claim to run.Article: 161292
"Hardware Construction Language": that's a good phrase. I write a lot of Matlab that generates Verilog. I wish I didn't have to, but that's the way it is.Article: 161293
Den 2019-03-23 kl. 05:43, skrev A.P.Richelieu:
> Den 2019-03-22 kl. 17:11, skrev Rob Gaddi:
>> On 3/21/19 9:37 PM, A.P.Richelieu wrote:
>>> Den 2019-03-21 kl. 19:40, skrev Benjamin Couillard:
>>>> It's been about 3 years since I've done any *serious* FPGA work. I
>>>> used mostly VHDL or sometimes my own Matlab scripts to create
>>>> automated VHDL files.
>>>>
>>>> I would like to know if anyone has used High-level synthesis
>>>> recetnly for *real* work and if so, would they recommend that people
>>>> learn it?
>>>>
>>>>
>>>>
>>>
>>> We are working on a system where we connect an FPGA and a CPU.
>>> The FPGA will implement almost 20-30 peripherals.
>>> The CPU will run Linux, and will need a driver for each type
>>> of peripheral.
>>>
>>> The Linux driver for each peripheral type will contain a main header
>>> file, and a file describing the user interface (I.E: the peripheral
>>> registers)
>>>
>>> A register could look like:
>>>
>>> typedef struct uart_mode_s {
>>> uint32_t bits:4;
>>> uint32_t parity:1;
>>> uint32_t odd:1;
>>> uint32_t encoding:2;
>>> uint32_t baud:24;
>>> } uart_mode_t;
>>>
>>> I use the register header file as input to a Python program to
>>> generate the register in VHDL. The Python program will generate a
>>> package
>>> containing the register with a std_logic_vector, and functions which
>>> will convert to and from a "record" so I can use the high level view
>>> of the register in VHDL.
>>>
>>> If I change the C header file in the driver, then the VHDL code will
>>> also change, due to dependencies in the build.
>>>
>>> Plan to have another Python program which will take a CSV
>>> file and use the contents to instantiate peripherals, and
>>> to generate the interface to the processor, including the address
>>> decoding. (Perhaps a JSON file will be better, though)
>>>
>>> This allows me to adopt to changing requirements and save a lot of time
>>> as well as keeping the driver and the peripheral in sync.
>>>
>>> I know others that do it the same way.
>>>
>>> AP
>>
>> If you haven't gotten too deep into writing your own code yet, you may
>> want to check out a project I've been working on sporadically for a
>> while now. https://github.com/NJDFan/register-maps
>>
>> There's also a more standard format for describing registers, IP-XACT,
>> which like mine is XML-based. I found it impossibly obtuse to work
>> with, but note it for the record.
>>
>
> Thank You,
> I will have a look.
> I was discussing this with the guy that has generated the FPGA
> code for my current project, and he suggested an XML based
> approach instead of C.
> If I was going that route, to start from a description and
> generate both C and VHDL, I would probably use a JSON format,
> since they are so much easier to read.
>
> In my mind the best way is to start off with the C driver.
> If you like us are running Linux & U-Boot, then you
> have an API for the driver, which needs to be followed.
>
> The H/W implementation of all the peripherals I have seen basically
> suck, and the C driver implementer has to overcome all the deficiencies
> forced upon him/her by the chip designers.
>
> The proper approach is to start with the API and then
> figure out how to implement this in a driver in the most efficient way.
>
> spi_xfer(peripheral SPI, uint8_t src, size_t size, enum spi_flags flags)
> {
> SPI->START = flags; // Activate CS on request
> strncpy(SPI->FIFO, src, size);
> SPI->STOP = flags; // Deactivate CS on request
> }
>
> Once I have the driver figured out, I already have the headers,
> so I do not want to create XML to regenerate what I already have.
>
> AP
Had a brief look at your stuff at
* https://github.com/NJDFan/register-maps
This is mainly to do address decoding, right?
Do you have any support for the actual fields inside the registers?
That is a primary function I would be looking for.
I can actually see the use of such tool for me,
if my C struct parser generates the XML (or JSON)
for an intermediate representation.
BR
AP
Article: 161294On Sat, 23 Mar 2019 19:45:06 -0700 (PDT) Kevin Neilson <kevin.neilson@xilinx.com> wrote: > "Hardware Construction Language": that's a good phrase. I write a lot of Matlab that generates Verilog. I wish I didn't have to, but that's the way it is. Could you construct and simulate with MyHDL? The verilog would then be just a simple export. [1] Jan Coombs -- [1] MyHDL - From Python to Silicon! http://www.myhdl.org/Article: 161295
Hi all, New to this list. I'm Gerard, Ham Radio operator F6EEQ. I have a Papilio Pro(Xilinx Spartan 6 LX)development platform since 5 or 6 years. But did not di much with it. Read an article in G-QRP club magazine "SPRAT" about DDS with FPGA and this renewed my interest. Hope to find much help and info here. See you soon. GerardArticle: 161296
On Sunday, March 24, 2019 at 9:00:36 AM UTC-4, F6...@wanadoo.fr wrote: > Hi all, >=20 > New to this list. > I'm Gerard, Ham Radio operator F6EEQ. >=20 > I have a Papilio Pro(Xilinx Spartan 6 LX)development platform since 5 or = 6 years. >=20 > But did not di much with it. >=20 > Read an article in G-QRP club magazine "SPRAT" about DDS with FPGA and th= is renewed my interest. >=20 > Hope to find much help and info here. >=20 > See you soon. I know that for radio work, spurs are very important. In particular, spurs= close to the carrier frequency are important to keep low since it is hard = to filter them out. The biggest cause of spurs close to the carrier in a D= DS is truncation of the phase word. The simple way to avoid phase truncati= on is to not truncate the phase word. lol But often this does not provide= adequate frequency resolution.=20 In case you are not familiar with the structure of a DDS, let me review. T= here is a clock driving an incrementer which adds the phase step on each cl= ock cycle. The output of this is the phase word. The incrementer has a mo= dulus at which point the count wraps around. Often binary, it can be any v= alue and the counter can be any bit width. The resolution of the phase ste= p determines the frequency resolution of the DDS. =20 Not all of the phase word bits are fed to the next section, the sine genera= tor. This is often a simple look up table (LUT), but to get good resolutio= n and low spurs more complicated methods are needed. A pair of smaller LUT= s appriately combined allow a wider phase word input to minimize phase trun= cation spurs. They are combined to approximate the equation sin(A + B) =3D sin A cos B + cos A sin B =20 cos(A + B) =3D cos A cos B =E2=88=92 sin A sin B If A and B are the upper and lower bits respectively in a phase word, sin(B= ) will always be small and cos(B) will always be close to 1. Both will be = relatively linear. In both equations the cos(B) term can be replaced with = 1.=20 sin(A + B) =3D sin A + cos A sin B =20 cos(A + B) =3D cos A =E2=88=92 sin A sin B Using a lookup table for sin/cos of A and another, smaller table for sin(B)= (since not all phase bits are needed) the sine and cosine of the full phas= e word A+B can be calculated with a pair of multiplications and adds. The = same LUT can be used for sin(A) and cos(A) by using two address ports and t= wo output ports which are common on block rams in FPGAs.=20 There is a way to not use the smaller LUT for sin(B) by taking advantage of= sin(B) being very linear, but I don't recall the details at the moment.=20 This more complex sine generator is used to utilize as much of the phase wo= rd as possible to minimize the close in spurs caused by phase word truncati= on. The remaining spurs caused by the other sources including the DAC, can= be minimized by cleaning up the output signal with a PLL if practical and = required.=20 Other methods of generating the sine wave use various numbers of terms from= approximations like the Taylor series. Then there is the CORDIC algorithm= which is about the complexity of a multiplication, but can't be done using= the on chip multipliers.=20 I hope this helps.=20 If you want to get fancy, here is a paper on a combined CORDIC and Taylor s= eries method that seems to be smaller than the CORDIC alone.=20 https://hal.archives-ouvertes.fr/hal-00516790/document Rick C.Article: 161297
On Sunday, March 24, 2019 at 8:31:34 AM UTC+1, Jan Coombs wrote: > On Sat, 23 Mar 2019 19:45:06 -0700 (PDT) > Kevin Neilson wrote: > > > "Hardware Construction Language": that's a good phrase. I write a lot of Matlab that generates Verilog. I wish I didn't have to, but that's the way it is. > > Could you construct and simulate with MyHDL? The verilog > would then be just a simple export. [1] > > Jan Coombs I read on the myhdl discourse that there seems to be a problem with the myhdl owner not maintaining myhdl the way a proper project owner should. Care to comment on that? -- SvennArticle: 161298
I write my models in Matlab so I'm going to stick with that. Once the model works in Matlab, I used functions I have to generate very low-level Verilog for things like Galois field matrix multipliers.Article: 161299
On Sun, 24 Mar 2019 08:46:20 -0700 (PDT) Svenn Are Bjerkem <svenn.bjerkem@gmail.com> wrote: > On Sunday, March 24, 2019 at 8:31:34 AM UTC+1, Jan Coombs wrote: > > On Sat, 23 Mar 2019 19:45:06 -0700 (PDT) > > Kevin Neilson wrote: > > > > > "Hardware Construction Language": that's a good phrase. I write a lot of Matlab that generates Verilog. I wish I didn't have to, but that's the way it is. > > > > Could you construct and simulate with MyHDL? The verilog > > would then be just a simple export. [1] > > > > Jan Coombs > > I read on the myhdl discourse that there seems to be a problem with the myhdl owner not maintaining myhdl the way a proper project owner should. Care to comment on that? Yes, this is a problem. The BDFL found time to consolidate progress to a 0.10 release. The team look capable, but their interests will likely diverge/fork if the leadership does not improve. What else combines the constructional power of the Python ecosystem, with simulation speed equal to other free tools [1], and spits out Verilog or VHDL? > -- > Svenn Jan Coombs -- [1] Performance - MyHDL is fast! http://www.myhdl.org/docs/performance.html
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