such uses. Looks like they also have M3 for FPGAs as well, they even ment ion using them for "free" which I assume means evaluation.
As
on to Xilinx parts, but I could not find out how to get it. I'm sure there are many qualifications. Ts & Cs.
om ARM
il you
ong as
t from Xilinx rather than ARM.
ardcore
have to sign paperwork or click on the web page link that acknowledges you agree to the contract to use a Zynq?
ork. Otherwise I've never seen that, web pages excepted. Digikey makes me agree to something with each new tab I open. Silly.
e bottle neck in the ARM chip were something like Flash. In general an FPG A will run more slowly than any manner of dedicated chip. The routing adds delay to every path. FPGAs can be fast simply because they can be tailore d to the task rather than executing general code to do what you want. Thin k of a processor with one instruction, your task. Maybe that's not a good analogy. But FPGAs aren't faster than processors, just more targeted so le ss wasted time doing things that aren't accomplishing the task, like fetchi ng instructions.
hardware to do what you need directly rather than thinking of what the proc essor is capable of or how the language is going to generate code to do the task. With HDL, if you describe the hardware properly, it will give you e xactly what you ask for. That's way it's a Hardware Description Language.
so it is an extreme case of not invented here, instead of understanding a l anguage, processor and peripherals, just reimplement everything from scratc h
uch uses. Looks like they also have M3 for FPGAs as well, they even mentio n using them for "free" which I assume means evaluation.
how
not
of the
you
the price
a special need to want a processor when you have a perfectly good FPGA.
many, many tiny bits of RAM in contrast to a processor which has the power of the humongous multiplexer manipulating very large blocks of RAM and Flas h. So the processor has to run very, very fast to create virtual connectio ns between the many portions of memory. The FPGA in contrast has wires con nected by routing FETs that can be used to connect the tiny multiplexers an d bits of RAM as selected by the multiplexers.
m with its humongous multiplexer selecting which task to emulate now, the F PGA is actually processing each task in parallel using much simpler resourc es for each task, fast or slow, it doesn't care.
rpreter
say this is all hardware the UI will be controlled by the FPGA. So yes, a n HDL UI is no big deal.
ting
You seem to be stuck in a rut that there is something difficult about HDL v s sequential languages. Icons are just bit blit. Why do you think any of the above is harder in an FPGA?
it be more expensive in an FPGA???
A processor with as much logic will be much more expensive. This is just a red herring. Use what gets the job done.
If you are talking about MB of memory, I've already conceded that such task s are not suited to HDL. Processors are uniquely suited for such tasks bec ause the primary element in the devices is a large block of memory. The pr ocessor is just the little bit required to do the processing in that memory . Think of the processing element in a Turing machine.
But in any event, memory is memory. It is neither more or less expensive i n FPGAs vs. processors.
ple often talk as if it is silly to design something in an FPGA that doesn' t require high speed or some other feature that makes it impossible to do i n an MCU. I look at problems from the other perspective, I only put in an MCU the parts that are awkward to do in an FPGA.
an MCU you try yo put it in the MCU, if you have both you put it where it m akes the most sense, keeping in mind that a lot more people can write code than HDL and the turn around for code it a lot shorter than HDL
Fallacy! HDL is not inherently slower to produce than sequential code. Se quential code often requires considerable thought about sharing the process or. But you are stuck in a rut where you want to compare the trivial seque ntial cases without considering the complex cases in the real world. The v ent we are working on has no "OS", but it has a "scheduler". I don't know how they are implementing it, but probably a round robin thing. This code simply would not exist in the FPGA and no one would need to give it any tho ugh.
rocess) there was nothing that could not be done in the FPGA, so no MCU nee ded. Of course it is a daughter board in a bigger system with lots of proc essors running operating systems virtualizing other operating systems... an d then they have bigger FPGAs than mine to do the real work.
signs can be done in FPGAs with no more trouble than in processors. But pe ople who use processors are used to thinking in the messy, complex techniqu es of making a sequentially executing machine appear to execute many proces ses at the same time.
20 years ago. Now that I have done some more complex designs in FPGAs I re alize it really isn't harder necessarily and can be easier since FPGA tools are optimized for simulation. Working in simulation allows so much to be verified without turning on power to a board. I think people underestimate that as well.
eople will keep using the tools they were taught. Now that they know the c omplex rules of making processors appear to process in parallel, there is l ittle incentive to change their thinking. So they will continue to fight t he same fights over and over.
ecause you have a hammer not everything is a nail, sometimes a screw is bet ter
Sure, but poor analogies are pointless here. My point is that people often don't understand the pros and cons and how they are really a reflection of preferences rather than real advantages.
You tell me of your 20 years experience and in the same post tell me that H DL takes longer to code... that says something very clearly to me about you r biases.
--
Rick C.
++- Get 1,000 miles of free Supercharging
++- Tesla referral code - https://ts.la/richard11209
such uses. Looks like they also have M3 for FPGAs as well, they even menti on using them for "free" which I assume means evaluation.
s
how
s not
r of the
n you
f the price
e a special need to want a processor when you have a perfectly good FPGA.
many, many tiny bits of RAM in contrast to a processor which has the power of the humongous multiplexer manipulating very large blocks of RAM and Fla sh. So the processor has to run very, very fast to create virtual connecti ons between the many portions of memory. The FPGA in contrast has wires co nnected by routing FETs that can be used to connect the tiny multiplexers a nd bits of RAM as selected by the multiplexers.
em with its humongous multiplexer selecting which task to emulate now, the FPGA is actually processing each task in parallel using much simpler resour ces for each task, fast or slow, it doesn't care.
erpreter
o say this is all hardware the UI will be controlled by the FPGA. So yes, an HDL UI is no big deal.
tting
it be more expensive in an FPGA???
If you need so much memory that you can't fit it on an FPGA you are probabl y using the wrong tool for the job. Use an MCU or an integrated part. Tal king about memory as if it is a bottle neck means you did a poor job of par titioning the design.
There are some parts in the Gowin lineup that include various forms of memo ry, system in package, multi-die, whatever they want to call it. Each solu tion has strengths and limitations. It's good to understand them well befo re choosing.
--
Rick C.
---- Get 1,000 miles of free Supercharging
---- Tesla referral code - https://ts.la/richard11209
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.