open-sourced FPGA (vhdl, verilog, C variants) design libraries, working toward a GNU (for hardware) paradigm

Certainly. That's what I do for a living. But the tight and efficient code I write for execution on a microcontroller is not likely to synthesize to an efficient FPGA implementation, because that wasn't what I was targetting. When I design hardware, I use very different optimization criteria.

That's a good example; can you add to this, code for a HC161/HC163, which is a 4 bit binary UP counter, with Sync preload, and Async/Sync reset ?

Are there other output choices, besides XNF ?

How do you verify operation ?

-jg

Depends on the tool. TMCC/FpgaC registers the state of every variable by default, and it takes a minor edit of the output netlist to remove the register. Or since it's open source, add a pragma option for output port to skip the register and customize the compiler for the project if there we more than a few that a script would easily fix.

With the existing TMCC/FpgaC compilers, probably not. But I'm sure this particular example was ment to force that answer. Certainly hand editing the VHDL or xnf output is pretty easy to effect that.

Can I modify TMCC/FpgaC to produce that from a specific form, as you would write for Verilog, sure, and it's probably not that hard. Optimization like those are not native to Verilog, or VHDL either, but are custom hacks that occur as the products mature for a specific target architecture.

Dave sent me an interesting hack that outputs as a VHDL netlist. -target vhd generate VHDL format -target stratix_vqm generate Altera Stratix VQM format -target xnf-gates generate XNF AND/OR/INV format -target xnf-roms generate XNF ROM format -target xnf-eqns generate XNF EQN format (default) -target flex8000 generate XNF AND/OR/INV format for Altera FLEX

it's not particularly readable, but useful to inputing into other tool chains. See below.

I just grabbed a copy of xnf2edf.exe from my older ISE release, and have a perl script to edit the output so I can target current Virtex, Virtex-II and Virtex-Pro parts. You probably noticed that the part specified was the XCV2000E's on my DINI DN2000K boards.

For this compiler, which is very simple, with some regression tests on the limited set of building blocks, and then generally trust the tools.

As with any design, you build into the process real on hardware testing at a functional level as well.

Since I'm mostly interested in reconfigurable computing in my use of FpgaC, I write, debug and test on a traditional processor ... and move pretested code to the FPGA.

For some past projects with TMCC I used several hardware test benches, which include two HP15600's with 1G DSO's and a couple hundred channels of 16555D's, plus some older HP1650/3's.

I've also rigged a VGA monitor and done typical software based printf outputs to the VGA monitor and single stepping on software break points at a level pretty close to the triggers in the HP's just by building in the debugging hardware as I needed it.

In a few cases I've done mixed tool designs with schematics and Verilog along with FpgaC blocks.

I've played a little with Celoxica Handel-C as well, they have a different strategy for building control state machines, but it works, and pretty well.

Other than the usefulness of being C, it's just another tool for getting projects done.

library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all;

entity example is port( CLK : in std_logic; RESET : in std_logic; a : in std_logic; b : in std_logic; c : in std_logic; d : in std_logic; sum_of_products : out std_logic ); end;

architecture arch_example of example is

signal T0_1_0Running : std_logic; signal T0_1_0Zero : std_logic; signal T0_2_L10_curstate : std_logic; signal T0_4_a : std_logic; signal T0_4_b : std_logic; signal T0_4_c : std_logic; signal T0_4_d : std_logic; signal T0_10_sum_of_products : std_logic; signal T0_14L31_T0_10_sum_of_products : std_logic; signal FFin_T0_1_0Running : std_logic; signal FFin_T0_1_0Zero : std_logic; signal FFin_T0_10_sum_of_products : std_logic;

begin

T0_4_a

For what it is worth, I've seen some pretty dismal FPGA designs come out of people who are supposedly digital designers too. It generally does take someone seasoned to turn out an FPGA design that uses the resources somewhat efficiently, that is going to be reliable, and that isn't going to spend a large part of the time to market in some lab chasing down countless naive design errors.

How many real-world designs have NO combinatorial outputs?

How does TMCC/FpgaC know *which* clock to use to register a given variable?

In reconfigurable computing, using FPGA's as a processor? ALL The reason is pretty simple, every variable is assumed to be some form of persistant memory in the C programming model. So, suprise, every statement which effects a variable assignment is assumed registered. After all, we are emulating CPU's and memory in reconfigurable computing.

Each program file in the TMCC/FpgaC model is assumed to use the same clock for a particular thread of execution.

You can bind different clocks to different files/threads.

To communicate between them requires building global variables which are written by one thread, and read by another. In the software world, these are mailboxes for communications. For more complex and higher bandwidth projects I have in the past built FIFO's in other tools, and included them in the FpgaC design at place and route.

How many PIC's and other microprocessors have combinatorial outputs? Maybe None? So why would using an FPGA to replace a CPU/memory be expected to be any different?

I think Xilinx now do the same, for their Abel flow - they output a 'not that readable, [but better than binary :)] VHDL' - the advantage being the simulation tools for VHDL then are available for ABEL. From those I now using this flow, Xilinx went backwards a little, then forwards, ( as one does..) and it now works very well.

-jg

It would requires more of the designer, but what about a pragma like the ASM one, in many C's ? - it would accept VHDL (or verilog), and pass on to the downstream tools. The advantage is it would understand the variable names, and scopes, of the other source ( much like in line asm does now ? ). If a LOT of HDL code was needed, then separate code modules would be better.

-jg

My comments are not aimed at Ray in particular, but I thought I would just note that that's true of embedded software also. Surely the point is that doing things efficiently and reliably (especially in resource limited environments) is Not Easy and you have to have competent (or better, depending on the project!) people doing it.

They also need good tools to do the job. Personally I'd love to get away from writing low-level VHDL for *some* of the things I do, but I wouldn't fancy writing an SDRAM controller in a C-like HDL either.

There's a phrase involving hammers and nails that springs to mind...

Cheers, Martin

There is a middle ground already available using standard vhdl synthesis that doesn't cost a dime or a gate or a flop.

I use single process entities with no signal declarations. I declare process variables for every local register and output port. I use functions to create values and procedures to collect and name all repeated command sequences.

I use exactly this template of three top procedures in every new design entity:

begin -- process template if reset = '1' then init_all_regs; -- no port init required elsif rising_edge(clock) then update_process_regs; end if; update_output_ports; -- wires ok for reset or clk end process template;

This style feels somewhat C-like but the template keeps me in "think hardware" mode.

-- Mike Treseler

Yep. Then the big difference starts, debugging in "think hardware" mode, or debugging in "think software" mode using source level debuggers with break points, single stepping and variable watching at a high level.

That's a hard one, and I've considered it several times, then backed off to using perl post processing of the XNF.

My current feeling is that it's probably wrong to do this in FpgaC, except maybe for the XNF outputs. The real problem here is that any feature such as an ASM, probably needs to be reasonably respresentable in any of the output forms for the net list. As we move from XNF to EDIF netlists, it gets even more difficult, because small changes need to be reflected into several different portions of the EDIF output, where at least XNF is pretty linear in that respect, just as machine language statements would be into an assembler. To be truthful, to make ASM work, the logic optimizations would have to be turned off, and the resulting netlist would get pretty bloated. There would also have to be some specific hacks to make the internal symbols visible, since there are not architecturally specified resources like machine registers that ASM would target in a traditional ISA machine.

The last arguement against it, is that it breaks the reason for making FpgaC as close to std C on a CPU/Memory, as the code is no longer directly testable on a traditional programming platform. So from this perspective it's better to push things that don't directly fit the std C model, into another HDL (Celoxica-C, VHDL, Verilog) and debug those parts separately using hardware simulators and hardware debuggers, and protect the ability to debug the rest of the C HLL system with stubs for the hardware interfaces and use more efficient HLL debugging tools.

It would not suprise me to see one or more people fork FpgaC to become an HDL for specific projects, or even take TMCC which was intended as an HDL and similarly extend it. If it makes sense at some point, maybe the FpgaC team will go ahead and do it, creating a second FpgaC_HDL tool chain.

There is likely to always be this dual headed monster of is FpgaC an HLL for reconfigurable computing, or an HDL for hardware design on FPGA's? My perspective is that doing the HDL side right requires a lot of optimizations for target FPGA's that are not particularly general. I believe it is possible to do FpgaC for reconfigurable computing uses that is a lot more general, less tied to target FPGAs, and this is the use that is not well supported by other HLL/HDL tools, paticularly when you consider test and debugging and the relatively horrible mess of using gate/timing simulators to debug HLL algorithms and multiple threaded applications with communications.

Seems to me that editing the output netlist is akin to editing a PCB design's Gerber files. There's a disconnect between the source, which in the FpgaC case is the C source file and in a PCB design the schematic, and the result, meaning either the final FPGA load or the finished PCB.

In other words, I want to look at the source and know that it matches the hardware.

-a

Actually I've used the analog comparators that are available on many PICs as combinatorial logic.

Modelsim does all of that for vhdl or verilog source code as well. In a single-process (or always block) design, tracing just one thread and watching variable values is very effective way to debug the logic description.

-- Mike Treseler

If that is what you want, you are certainly free not to do anything special.

the prototype, and then to use a script to fix/edit that prototype to create the final form for production. The general key is to document the process well, and manage it. The whole Xilinx tool chain used to be a series of net list edits from front to back, including the back annotation. I assume there are others that are also comfortable with post processes net lists with C and Perl tools to fix vendor bugs and to implement design requirements the vendor tool chain can not handle directly. In comes down to understanding the process you have, the changes needed to effect the desired results, and documenting the modified process carefully.

Post processing even Gerber files is very common. PCB houses used to do it regularly to adjust soldermasks and still do it for panalizing and inserting dead or active copper to manage plating density. Again, managed editing of the bit stream to finished product.

For years we used to post process C compiler output to fix known bugs on binary compiler products, and to do custom peep hole optimizations for specific target architectures. We used to use perl scripts to insert a new wrapper for C coded interrupt routines instead of having a lame asm wrapper. Of course, you can always bug report it, and wait till the next release to continue development or get the bugs fixed in the field.

Everyone has there own comfort level and standards.

That can be a dangerous style. Some tools are quite bad with VHDL procedures and functions. I have seen a some formal tools to create just insane netlists out of procedures, some synthesizers can have problems with them. Also some code chekers understand procedures quite badly and can show problems that are not real (they can't figure out the control flow and report extra latches that are not in reality there etc.)

Procedures are nice way to make the code clear to read, but unfortunately the tool support is still problematic. I can't understand what is so difficult in that support.

--Kim