Small, fast, resource-rich processor

Lol! I think the proof of the pudding is in the eating...

Yes, so you can run tools on an ARM to design the XC3000 chips with 500 LUTs. Go for it!

Yeah... I don't think the solution is to swim upstream against the FPGA makers. Why not try something that might actually work?

If all you want to do is to implement combinational logic, you don't need the FPGA compiling tools. The LUTs are small memories. I believe they can be configured in ways that allow you to both use them as logic and to change their contents. It is the interconnect that you won't be able to mess with. So configure a network of LUTs and then reload them at will to implement your logic. Where do I get my money?

--

Rick
Reply to
rickman
Loading thread data ...

They're chips that people load bits into. "Q. Why can I run my own compilers for the x86 but not the ARM? A. The ARM is not an x86 and you won't be able to understand it". I would just say I *do* understand it: one set of PHB's is stupider than the other set.

FPGA's have been around since the 1990's or maybe earlier. The tools ran on PC's of that era. Today's ARM's are about equivalent to those old PC's. So the tools should be able to run on today's ARM's.

The idea is you want to compile the filter directly to combinational logic so it can run at maximum speed. And the filters can be very complex and have a lot of stuff going on in parallel. It can't really be turned into fixed code with some parameters: that's why BPF generates machine code for CPU's. The idea of the FPGA version is to filter 100 gigabit DOS attacks:

formatting link

If it makes things more interesting to you, there is big money in this, if you can figure out how to make it happen.

Reply to
Paul Rubin

Well, there is also some state. And maybe complex computation in some situations, though probably not for DOS filtering.

Good plan. All you need now is the bitstream format.

You have much more flexibility if you can program the interconnect.

Reply to
Paul Rubin

Only for one level of the internal architecture - they don't give full details about the internal microarchitecture. They have decided that the asm code is the level of compatibility that they support.

With FPGAs, VHDL is the level of compatibility that they support.

With conventional processors changes to the internal microarchitecture often imply that the asm is different.

Ditto FPGAs and the VHDL.

Easy: spit out VHDL (or verilog) - that's the equivalent of asm.

Many HLL compilers spit out C. I first saw that the Kyoto LISP compiler back in the mid 80s. I'm sure it was done before and since.

I suspect you could reverse-engineer small changes.

For example, if you had a logic analyser in which a LUT was used to select which signal to use as the trigger, then you might be able to isolate which bits corresponded to each condition.

Of course, a different FPGA implies you start again.

Doing much more would, I suspect, require a GB of RAM and a lot of horsepower.

Reply to
Tom Gardner

OK, so your embedded device has LAN connectivity.

Somehow, somewhere, determine the specific filter's characteristics and upload that to a workstation on the LAN.

On the workstation, munge the spec into VHDL and use the manufacturer's toolset to convert to FPGA bits - which you then download to your embedded device and thence into the FPGA.

If appropriate, put the workstation somewhere on the net, not just on the LAN.

Sorry, you cannot patent that concept, since I've just disclosed it.

Alternatively, have the filter characteristics stored in RAM in the embedded device, and have the FPGA read and interpret that spec. At which point you have created a custom processor implemented in an FPGA, and the filter spec is your assembler code. Analogy: modern 80x86s interpret the asm code into many many internal risc-like micro-ops.

Sorry, you cannot patent that concept, since I've just disclosed it.

(BTW, I doubt "my concepts" are actually original! :)

Reply to
Tom Gardner

Not the same by a long stretch. As long as it is between source and object code, to be more precise.

So how does his embedded system convert the vhdl into a bitstream to feed into the fpga.

Dimiter

Reply to
dp

I can't understand what you mean, but my point is actually correct. I didn't claim it was "the same", whatever that might of might not mean.

I replied to a post that didn't mention an embedded system. However, see my response at 10:21 to one that did.

Reply to
Tom Gardner

OK, I somehow implied that you put asm (the kind which translates unambiguously into object code, not like say VPA) into the same box as vhdl (which is very loosely connected to the end binary data). Apparently I have misunderstood it.

Now if your suggestion to write a logic tool with vhdl as an output was a joke then I have misunderstood you again. But it is a joke, intended or not :-). The point of writing a tool is to have control over some process and avoid being controlled by someone else, hopefully this is obvious enough.

Dimiter

Reply to
dp

Ok, just to be more detailed. :-)

A PHB within the FPGA company sees that some people are using the tools for free. They figure that if they start charging for the tools, _some_ of the existing users will still pay for them and the PHB will see a increase in sales for the next couple of quarters or so.

They don't consider or care about the long term effect of driving new customers to their rivals - that's "not their problem".

Pretty much like Sun/Oracle did with Solaris, BTW...

One or two general ideas, but nothing too specific at the moment; just learning the technology will do to start with. My main problem is that the number of more developed ideas I have in other technology areas already exceeds my available spare time to work on them. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

David Brown

The number of atoms in the universe is estimated to be 1e80 within a couple of orders of magnitude. The square root of that would be about a 120-bit number. You'd think there would be a need.

Mel.

Reply to
Mel Wilson

I'm sorry - I should have been more explicit on the basis of comparison I am proposing: same number of bits for each.

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

David,

That's not what my copy of the C99 spec states (re: section 7.18.1.2):

The following types are required: int_least8_t int_least16_t int_least32_t int_least64_t uint_least8_t uint_least16_t uint_least32_t uint_least64_t All other types of this form are optional.

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

You mean like GMP (Gnu Multi-Precision)? Yeah, I know - just got done doing some coding with that library a few weeks back.

Just respondin'

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

YOU'RE assuming integer ends at 64-bit - there are higher precision integer libraries (e.g., GMP) out there...

(See my follow-up to rickman for the basis of comparison I intended)

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

Not a logic tool - a packet-level filter tool, presumably something /at least/ as expressive as iptables and probably more expressive.

That's lacking in imagination.

There are other purposes for tools, e.g. get to market faster, or have a more flexible product, or have a proprietary lock-in, or just to get the job done at all.

Reply to
Tom Gardner

Well a lot of things can be written which have various inputs and outputs, of course. This is infinite.

Well none of the examples you give actually works.

Reply to
dp

Ok, then the point is... pointless.

--

Rick
Reply to
rickman

PHB? Like a PhD but for Bean counting? lol

You can imagine any scenario you wish. The trend is in the opposite direction with each vendor vying against the others to squeeze a little more into the "free" tools. For some reason they don't support the very largest parts with the free tools. I expect this is a matter of profit, not the pittance they get from the tools, but they want anyone using their BIG parts (read that as BIG profit) to buy tools so they are registered and they can get *all* the help they need... not too much different from helping the little old lady across the street because you know she is worth billions.

This is getting a bit silly really. The design process for FPGAs is to write HDL code that is largely independent of vendor and can be compiled on any vendor's tools. Then for anyone not in a larger company with the bucks to waste, use the vendor's free (as in beer) tools to turn that HDL into a bitstream which can be used to program the FPGA. If you don't like the vendor for any number of reasons (like he doesn't "like" you anymore and changes something that dis's you) you can always switch to a different vendor.

Does that put you at risk of having hardware you can't support... it shouldn't because you can still use the old tools if you want. I'm still using tools from nearly 5 years ago when I stopped paying for the maintenance although if I do any more updates to my 5 year old design it will likely be with the free (as in beer) tools.

Don't let your distaste for commercial software ruin FPGAs for you. They are great stuff really. Imagine programming at the microcode level!

--

Rick
Reply to
rickman

Really? The amount of resources required to accomplish a task is pointless?

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

Or was that a joke? Sorry!

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.