> 
> You mean to program FPGAs directly from KTechLab ? Then probably yes, but 
> probably we can get away with running generic script. The toolchains for 
> FPGAs are generally closed-source (maybe only ICE40 has open-source 
> toolchain?).
> 
    No, not exactly.   That would require a compiler as well.  But that should 
not be a problem.  Let me explain.

   First, this would only be good for “small” projects.  Small is in the eye of 
the beholder.

   Second, there are a  Verilog simulators (open source) and compilers (open 
source) out there.  KTechLab may be able to integrate with one or more of them.

   Third, if KTechLab puts out a verilog file (and makes it apparent and 
available), then the verilog file could be fed into the command line compiler 
system for that CPU family, available from that manufacturer, usually for free 
(not as in beer).

   

    

> I think that for simulating Verilog, there is no need to synthesise for a 
> FPGA and load the RTL. Just process for simulation (hopefully with a 
> library..) Then I guess there shouldn't be issue with scalability. Maybe I'm 
> wrong?
> 
> 
> Best regards,
> 
>  Zoltan

    agreed.  A library approach would be nice.  However, I don’t think that the 
scale would have to be that large…see following.

----
Alan Grimes….

If i remember the architecture of this program at all at this point, it
would be a new document type that would be added to a project. I'm not
sure how scalable that will be as a FPGA can have millions of gates. A
few thousand gates, sure, but millions, that requires a higher level
approach..
-----


  KTechLab would (probably) not be suitable for generating an entire 
“professional” FPGA’s worth of information.

  However, to model “small”  (less than a thousand) gates for an SOC or MCU 
project, I think it would be ideal.

  The goal here (in my mind) would be to produce some file (verilog in my case) 
that can be fed into another compile system and used, after KTechLab maybe 
shows it works.  (Why duplicate work by having to recode by hand in Verilog 
from a working schematic?)

   
  In my opinion, SOC or MCU projects will never need more than several hundred 
or thousand gates.  For an economic reason, and almost by definition, SOC or 
MCU units in IOT or standalone systems will not need many gates to do the 
project they are tasked to do. 

  The reason is cost.  SOC and MCU units are in the $10 range (in single 
pieces) down to less than $1.   That will preclude large FPGA technology for 
probably a decade or so.  If you need a million gates, you will use Xilinx 
development system, Altera system, or some other manufacturer’s system and a 
large part.  You will create your own System for the SOC, with the CPU being 
part of the fabric.  These development systems all use verilog or VHDL files.  
(Which leads to the concept you could TechLab the problem in pieces and feed to 
the bigger Development Kits (DK)).

  If I am off base, no problem. I am trying to solve a problem I see in the 
near future.   I think visually, where electronics are concerned.  This rush by 
manufacturers to kill off visual development tools concerns me greatly.
  
  So, in conclusion, SMALL is excellent for this.  Verilog output (from 
templates?) would be excellent, to be fed into simulators or compilers or 
larger DK’s.



Thanks!

Wade

  (Note: I made money developing on Xilinx systems.  I spent much more time 
fighting the Xilinx development system than I ever did fighting my design.  I 
used VHDL, because for some reason, that particular system (around 9, 10, or 11 
in their XDK hierarchy) barfed on verilog. At the time, Xilinx support could 
not solve the problem with me. (probably my fault)  It was easier to pick up 
VHDL than to fix the XDK.  Wik KTL, there is a good chance the DK from people 
like Xilinx could be more easily managed.)




_______________________________________________
Ktechlab-devel mailing list
Ktechlab-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ktechlab-devel

Reply via email to