sounds good, but many times it is difficult to really find out WHY there is a difference in the simulation results]
Design complexity naturally makes this difficult, but it could be made easier if the tools were user friendly.
The tools start by assuming the design is complete and they do not provide efficient iterations as the design evolves. The early stages of design do not need synthesis to optimize away major pieces of logic, nor does it need place and route, and timing analysis should be deferred to the physical design stage. These things are in the flow and consume a lot of time and may be necessary to produce RTL that conventional simulators use.
Just realizing a few basics and producing user friendly tools can help a lot.
Hardware consists of data flow and control logic. Data flow is routine no matter the form of design entry. The "balloon/cloud" of control logic is most error prone. The most concise way to define control logic is with Boolean algebra. Simulation is fast and easy especially with synchronous logic, Boolean is text and easily parsed, can be entered as text or HDL can be parsed into Boolean. i.e. a string of if's make an and, else is negation, etc.
On the programming side, optimizing C compilers love to throw away the code used to interface with memory mapped IO, so there should be an embedded C, not the application standard with all the libraries, memory allocation, pointer arithmetic, stack overflows, etc.
I wish this kind of paper used more actual examples (maybe from happy customers) that showed a real success. These types of solutions often sound good on paper, but when you actually try and use the tool tricky issues crop up. For example, the example
"the team can compare the simulation results directly with the results obtained when the block is instantiated in the FPGA. The team can precisely see where the two diverge and systematically determine the problem"
sounds good, but many times it is difficult to really find out WHY there is a difference in the simulation results. An error may not show up for many cycles in an embedded design. Now, if you can help me with that problem, I'm interested...
If there's one hot area in electronics design at the moment, that area is FPGAs, which are appearing in all sorts of applications for which they would never have been considered only a few short years ago...
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.