forsyde / forsyde-deep Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
Issue by HWoidt
Thursday Jul 09, 2015 at 12:28 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/3
There exist a large number of FIXME markers in the source code. The important ones should be summarized into issues to keep track of them.
Issue by HWoidt
Saturday Jul 11, 2015 at 13:03 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/14
Reported by [email protected], May 16, 2008
ForSyDe.Process.defArgVal and ForSyDe.Process.defArgPF are totally ignored
by the VHDL backend
Issue by HWoidt
Saturday Jul 11, 2015 at 13:06 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/19
Reported by [email protected], Aug 9, 2008
Now, the output signals of a node are modeled by tagging the graph edges
connected to that node. However, that's quite inconvenient (and
inefficient) in practice.
Even if a better model cannot be found (which I doubt) at least we should
create a variant of NlNode which takes outputs in account.
data NlNodeIO inputi outputi =
-- Ports
InPort PortId | -- ^ Input Ports of the system
-- Processes
Proc ProcId (NlProc inputi)
data NlProc inputi outputi =
...
ZipWithNSY (TypedProcFun Dynamic) -- Process function in dynamic form
[inputi] outputi
...
GHC 8.0.1 is out. A cursory glance at the migration guide did not raise any alarms with me but we still need to check, whether everything works. There are also some new features that might be interesting (although we should not introduce any changes that break backwards compatibility for GHC 7.10):
https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/8.0.1-notes.html
https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0
Issue by HWoidt
Thursday Jul 09, 2015 at 12:53 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/10
There are quite a few redundant imports. They should be removed.
Issue by HWoidt
Saturday Jul 11, 2015 at 13:01 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/12
Reported by [email protected], Apr 23, 2008
In order to model for instance buses a tri-state data type is needed.
std_logic in VHDL provides 9 different values, the most important are '1',
'0', 'Z' (high resistance) and 'X' (unknown).
How difficult would it be to implement it?
Apr 24, 2008
Project Member [email protected]
OK, sounds reasonable. On the other hand ... wouldn't it be better to just have one
type (e.g. StdLogic) instead of two (Bit + StdLogic)? Actually, Bit is currently
translated to std_logic.
I never really understood why VHDL makes use of both.
Apr 24, 2008
Project Member [email protected]
Let's think a little bit more about it. The full std_logic data type is not needed
for synthesis. One should have 'Z' and maybe 'X' is also used (for don't care, but we
have to check this further).
Issue by ingo-sander
Friday Jan 15, 2016 at 09:23 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/26
I would like to have a simple command forsydeVersion
, which gives me a version number and maybe additional information. Ideally the version number should include also the version number of the git-repository.
Something like
> forsydeVersion
forsyde-deep 0.2.1 - revision 288
This would simplify the discussion and avoid confusion.
Issue by HWoidt
Thursday Jul 09, 2015 at 12:48 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/7
Creating "SysFun()" with template Haskell produces an empty pattern which causes a warning.
Fix: Add a special case for this instantiation which omits that pattern.
The previous ForSyDe-Deep web page has to be migrated and updated.
Issue by HWoidt
Saturday Jan 23, 2016 at 07:29 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/27
ForSyDe.Deep runs on GHC7.10 in principle.
There is still one important issue left, which should be revisited before merge: #23
HWoidt included the following code: https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/27/commits
Issue by HWoidt
Saturday Jul 11, 2015 at 13:08 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/21
Reported by [email protected], Jan 19, 2010
When a splice is run, Template Haskell now provides line and file
information through "qLocation :: m Loc". I think ForSyDe should take
advantage of it.
Issue by HWoidt
Saturday Jul 11, 2015 at 13:04 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/15
Reported by [email protected], May 16, 2008
Currently, the VHDL backend is only able to translate naive case
expressions. There is no support pattern-matching with tuples AbsExt
expresions.
Issue by HWoidt
Wednesday Feb 03, 2016 at 18:25 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/28
Issue by HWoidt
Tuesday Feb 09, 2016 at 16:13 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/31
This fixes issue #10 "remove redundant imports"
HWoidt included the following code: https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/31/commits
Issue by HWoidt
Saturday Jul 11, 2015 at 13:03 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/13
Reported by [email protected], Apr 24, 2008
Support for translation of FSVec and Tuple primitives:
Issue by ingo-sander
Thursday Jan 14, 2016 at 14:42 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/24
There seems to be a bug in the simulation with Modelsim.
When I simulate the counter example then Modelsim produces an error. I have not analyzed it further, but it might have to do with reset or the clock input. So, please ensure that a Modelsim simulation generates the trace for the clock signal and resets all flip-flops at the beginning of the simulation.
Here comes the code for the counter:
{-# LANGUAGE TemplateHaskell #-}
module CounterHW (Direction, counterSys) where
import ForSyDe.Deep
import Data.Int
type Direction = Bit
nextStateFun :: ProcFun (Int8 -> Direction -> Int8)
nextStateFun = $(newProcFun
[d| nextState state dir
= if dir == H then
if state < 9 then state + 1
else 0
else
if state == 0 then 9
else state - 1
|])
counterProc :: Signal Direction -> Signal Int8
counterProc = scanldSY "counterProc" nextStateFun 0
counterSys :: SysDef (Signal Direction -> Signal Int8)
counterSys = newSysDef counterProc "Counter" ["direction"] ["number"]
And here is the simulation output:
ingo@s2135:counter7Seg> ghci CounterHW.hs
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling CounterHW ( CounterHW.hs, interpreted )
CounterHW.hs:26:70: Warning: Tab character
Ok, modules loaded: CounterHW.
*CounterHW> simulate counterSys [L,H,H,H,H,L,L,L,L]
[0,9,0,1,2,3,2,1,0]
*CounterHW> let vhdlSim = writeAndModelsimVHDL Nothing counterSys
*CounterHW> vhdlSim [L,H,H,H,H,L,L,L,L]
Running: vmap forsyde /home/ingo/.cabal/share/x86_64-linux-ghc-7.10.3/ForSyDe-Deep-0.2.0/lib/modelsim
Modifying modelsim.ini
Running: vlib Counter_lib/modelsim
Running: vcom -93 -quiet -nologo -work Counter_lib/modelsim Counter_lib/Counter_lib.vhd
Running: vmap Counter_lib Counter_lib/modelsim
Modifying modelsim.ini
Running: vlib work/modelsim
Running: vcom -93 -quiet -nologo -work work/modelsim -just e work/Counter.vhd
Running: vcom -93 -quiet -nologo -work work/modelsim -just a work/Counter.vhd
Running: vmap work work/modelsim
Modifying modelsim.ini
Running: vcom -93 -quiet -nologo -work work test/Counter_tb.vhd
Running: vsim -c -std_output /tmp/tb_out1804289383846930886.txt -quiet -do run 90 ns; exit work.Counter_tb
Reading /opt/altera/13.0/modelsim_ae/tcl/vsim/pref.tcl
#10.1d
# vsim -do {run 90 ns; exit} -c -quiet -std_output /tmp/tb_out1804289383846930886.txt work.Counter_tb
# // ModelSim ALTERA 10.1d Nov 2 2012 Linux 3.13.0-74-generic
# //
# // Copyright 1991-2012 Mentor Graphics Corporation
# // All Rights Reserved.
# //
# // THIS WORK CONTAINS TRADE SECRET AND PROPRIETARY INFORMATION
# // WHICH IS THE PROPERTY OF MENTOR GRAPHICS CORPORATION OR ITS
# // LICENSORS AND IS SUBJECT TO LICENSE TERMS.
# //
# run 90 ns
# ** Fatal: (vsim-3421) Value -129 for return value is out of range -128 to 127.
# Time: 0 ps Iteration: 0 Process: /counter_tb/totest/\counterProc_NxtSt\/line__49 File: work/Counter.vhd
# Fatal error in Subprogram \nextState_0\ at work/Counter.vhd line 44
#
# HDL call sequence:
# Stopped at work/Counter.vhd 44 Subprogram \nextState_0\
# called from work/Counter.vhd 50 Block \counterProc_NxtSt\
#
# exit
[]
Issue by HWoidt
Thursday Jul 09, 2015 at 12:45 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/6
There are lots of deprecation warnings for ghc-7.10 and ghc-8.0.1
Issue by HWoidt
Friday Jan 15, 2016 at 01:53 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/25
This should solve the simulation issue #24 concerning the initial value of internal signals.
HWoidt included the following code: https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/25/commits
Issue by HWoidt
Saturday Jul 11, 2015 at 13:09 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/22
Reported by joaopizani, Nov 24, 2010
I've written a VERY simple RLE encoder using ForSyDe's deep-embedded API, intending to synthesize it. Simulation with "simulate" went well, and ForSyDe generated VHDL. But in the library generated by ForSyDe (rle_lib.vhd) the VHDL functions for verifying if an AbstExt value is present, and the Prst constructor are missing.
They are replaced by duplicate instances of "absent" functions. If I just replace the word "absent" by "present" in two places in the VHDL code, the project synthesizes and works beautifully...
What steps will reproduce the problem?
What is the expected output? What do you see instead?
Expected the VHDL design and libraries to compiles and synthesize successfully. Instead, when running the compilation in Quartus, it complains with the following error message:
"Error (10289): VHDL Subprogram Specification error at rle_lib.vhd(43): subprogram "absent" is a homograph of another object in the same declarative region"
It turns out that this declaration, and the corresponding definition are really duplicate. But if I replace both occurrences of "absent" by "present" it all works.
What version of the product are you using? On what operating system?
ForSyDe 3.1.1 (from Hackage)
Haskell Platform 2010.2.0.0
GHC 6.12.3
Quartus 10.0
Ubuntu 10.10
Please provide any additional information below.
I have made a small diff file from the comparison between what is generated by ForSyDe and what works. Here it is:
30c30
< function absent (extabst : tup_2_int8_int16)
---
> function present (extabst : tup_2_int8_int16)
40c40
< function absent (extabst : abs_ext_tup_2_int8_int16)
---
> function present (extabst : abs_ext_tup_2_int8_int16)
75c75
< function absent (extabst : tup_2_int8_int16)
---
> function present (extabst : tup_2_int8_int16)
98c98
< function absent (extabst : abs_ext_tup_2_int8_int16)
---
> function present (extabst : abs_ext_tup_2_int8_int16)
Issue by HWoidt
Monday Feb 08, 2016 at 10:50 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/30
It would be nice to have ghc 7.8.4 compatibility if possible since this is still a popular release.
Issue by HWoidt
Saturday Jul 11, 2015 at 13:04 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/17
Reported by [email protected], Aug 4, 2008
According to the VHDL'93 standard, the minimum guaranteed range for any
implementation if INTEGER is -2147483647 to 2147483647 (which matches the
range implemented by Modelsim 6.1g (Included with Quartus 7.2)).
However, the range of a 32-bit Two complement's representation (Int32) is
-2147483648 to 2147483647, making it overflow.
What should be done here?
Issue by HWoidt
Thursday Jul 09, 2015 at 12:39 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/5
The test cases ALU and ButtonEncoder fail with an "Unsupported Type" error:
### Error in: 0:VHDL Backend Test:0:aluTest
VHDL Compilation Error: Unsupported type Bit
in process function `fullAddFun_0' (created in ALU) used by process `fulladd' belonging to system definition `fullAddSys' (created in <unkown>)
### Error in: 0:VHDL Backend Test:6:buttonEncoderTest
VHDL Compilation Error: Unsupported type Direction
in process function `transFun_0' (created in ButtonEncoder) used by process `encoder' belonging to system definition `buttonEncoder' (created in <unkown>)
This is due to wrong strings being compared in the enumType registry during translation:
enumTypes = fromList [EnumAlgTy "Bit" ["H","L"]]
lookupKey = "ForSyDe.Deep.Bit.Bit"
This should be resolved by either
Issue by ingo-sander
Friday Dec 25, 2015 at 14:50 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/23
There seems to be a problem with the synthesis of FSVec, which becomes visible in the SimpleDES_HW.hs example. The normal 'compileQuartus', which synthesizes the fSys-subsystem works, but there is a problem with the full example, where FSVec D5 Bit cannot be synthesized.
Check the code below:
ingo@hsv:examples> ghci SimpleDES_HW.hs
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling SimpleDES_HW ( SimpleDES_HW.hs, interpreted )
Ok, modules loaded: SimpleDES_HW.
SimpleDES_HW> compileQuartus_subkeysSys
** Exception: VHDL Compilation Error: Unsupported type FSVec D5 Bit
in process function subkeys_0' (created in SimpleDES_HW) used by process
subKeys' belonging to system definition `genSubkeys' (created in )
*SimpleDES_HW> :q
Leaving GHCi.
Issue by HWoidt
Thursday Jul 09, 2015 at 12:51 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/9
For the new test suite configuration to be usable, the library should to be compiled
alongside the generated vhdl files.
This would have several positive effects:
The only downside would be additional effort when recompiling the
package. Since forsyde.vhd only contains a couple of functions this is
not of great concern.
Issue by HWoidt
Monday Feb 08, 2016 at 10:25 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/29
Data.Typeable.FSDTypeRepLib implements a wrapper around haskells own
Data.Typeable TypeRep/TyCon. This wrapper eliminates the package field
of the type, thus making it possible to construct it from template
haskell type objects.
This commit introduces the new type and changes all uses of the original
TypeRep with the new FSDTypeRep. Among others this fixes #23
[23] https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/23
HWoidt included the following code: https://gits-15.sys.kth.se/ingo/forsyde-deep/pull/29/commits
Hi, I found that the generated VHDL code for 'take' function in Data.Param.FSVec cannot be simulated by writeAndModelsimVHDL. Here is a small example.
{-# LANGUAGE TemplateHaskell #-}
module Take where
import ForSyDe.Deep
import Data.Int
import Data.TypeLevel
import Data.Param.FSVec
takeProcFun :: ProcFun(FSVec D3 Int32 -> FSVec D1 Int32)
takeProcFun = $(newProcFun
[d| takeProcFun :: FSVec D3 Int32 -> FSVec D1 Int32
takeProcFun x = Data.Param.FSVec.take d1 x
|])
takeProc :: Signal (FSVec D3 Int32) -> Signal (FSVec D1 Int32)
takeProc = mapSY "proc1" takeProcFun
takeSysDef :: SysDef(Signal (FSVec D3 Int32) -> Signal (FSVec D1 Int32))
takeSysDef = newSysDef takeProc "mingzi" ["in"] ["out"]
x1 = (1 :: Int32) +> (2 :: Int32) +> (3 :: Int32) +> empty
x2 = (4 :: Int32) +> (5 :: Int32) +> (6 :: Int32) +> empty
The simulation in ForSyDe.Deep is fine.
simulate takeSysDef [x1, x2]
[<1>,<4>]
But the simulation in Modelsim failed.
writeAndModelsimVHDL Nothing takeSysDef [x1, x2]
Running: vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim
Modifying modelsim.ini
Running: vlib mingzi_lib/modelsim
** Warning: (vlib-34) Library already exists at "mingzi_lib/modelsim".
Running: vcom -93 -quiet -nologo -work mingzi_lib/modelsim mingzi_lib/mingzi_lib.vhd
** Warning: mingzi_lib/mingzi_lib.vhd(127): (vcom-1246) Range 0 to -1 is null.
Running: vmap mingzi_lib mingzi_lib/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap mingzi_lib mingzi_lib/modelsim
Modifying modelsim.ini
Running: vlib work/modelsim
** Warning: (vlib-34) Library already exists at "work/modelsim".
Running: vcom -93 -quiet -nologo -work work/modelsim -just e work/mingzi.vhd
Running: vcom -93 -quiet -nologo -work work/modelsim -just a work/mingzi.vhd
Running: vmap work work/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap work work/modelsim
Modifying modelsim.ini
Running: vcom -93 -quiet -nologo -work work test/mingzi_tb.vhd
Running: vsim -c -std_output /tmp/tb_out7198853861649760492.txt -quiet -do run 20 ns; exit work.mingzi_tb
Reading pref.tcl
# 2020.1
# vsim -c -std_output /tmp/tb_out7198853861649760492.txt -quiet -do "run 20 ns; exit" work.mingzi_tb
# Start time: 00:51:37 on Oct 23,2022
# run 20 ns
# ** Fatal: (vsim-3420) Array lengths do not match. Left is 1 (0 to 0). Right is 0 (1 to 0 (null array)).
# Time: 0 ps Iteration: 0 Process: /mingzi_tb/totest/\proc1\/line__31 File: mingzi_lib/mingzi_lib.vhd
# Fatal error in Subprogram take at mingzi_lib/mingzi_lib.vhd line 187
#
# HDL call sequence:
# Stopped at mingzi_lib/mingzi_lib.vhd 187 Subprogram take
# called from work/mingzi.vhd 28 Subprogram \takeProcFun_0\
# called from work/mingzi.vhd 31 Block \proc1\
#
# exit
# End time: 00:51:37 on Oct 23,2022, Elapsed time: 0:00:00
# Errors: 1, Warnings: 0
[]
For the simulation in Quartus, I am still struggling.
Issue by HWoidt
Thursday Jul 09, 2015 at 12:27 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/2
There exist unsolved issues in the old google-code tracker. They should be incorporated here.
http://code.google.com/p/forsyde-comp/issues/list
Note that google code will be closed at the end of 2016:
January 25, 2016 - The project hosting service is closed. You will be able to download a tarball of project source, issues, and wikis. These tarballs will be available throughout the rest of 2016.
Issue by HWoidt
Saturday Jul 11, 2015 at 13:07 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/20
Reported by [email protected], Jan 19, 2010
To reproduce the problem:
The VHDL backend generates the output sub-functions in the VHDL code in the
same order as were defined in the design. This may result to using a
function in the VHDL code before defining it.
As a workaround, the designer could define the functions in the
define-then-use order which is not a common practice in functional programming.
Issue by HWoidt
Thursday Jul 09, 2015 at 12:23 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/1
Currently Forsyde 3.1.1. is the latest release on Hackage. To which git revision does this relate?
The current version of forsyde-deep
fails when compiled with ghc-8.2.2
. It needs to be ported.
Hi. I find there is also something wrong with multi-dimensional fixed size vector. The simulation in forsyde deep is fine, but the generated VHDL code cannot be simulated.
My code is:
{-# LANGUAGE TemplateHaskell #-}
module Take where
import ForSyDe.Deep
import Data.Int
import Data.TypeLevel
import Data.Param.FSVec
takeProcFun :: ProcFun(FSVec D2 (FSVec D2 Int32) -> FSVec D2 (FSVec D2 Int32))
takeProcFun = $(newProcFun
[d| takeProcFun :: FSVec D2 (FSVec D2 Int32) -> FSVec D2 (FSVec D2 Int32)
takeProcFun x = x
|])
takeProc :: Signal (FSVec D2 (FSVec D2 Int32)) -> Signal (FSVec D2 (FSVec D2 Int32))
takeProc = mapSY "proc1" takeProcFun
takeSysDef :: SysDef(Signal (FSVec D2 (FSVec D2 Int32)) -> Signal (FSVec D2 (FSVec D2 Int32)))
takeSysDef = newSysDef takeProc "mingzi" ["in"] ["out"]
x1 = (1 :: Int32) +> (2 :: Int32) +> empty
x2 = (4 :: Int32) +> (5 :: Int32) +> empty
y1 = x1 +> x2 +> empty
The simulation result in forsyde deep is:
simulate takeSysDef [y1]
[<<1,2>,<4,5>>]
But error happens in modelsim simulation:
writeAndModelsimVHDL Nothing takeSysDef [y1]
Running: vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim
Modifying modelsim.ini
Running: vlib mingzi_lib/modelsim
** Warning: (vlib-34) Library already exists at "mingzi_lib/modelsim".
Running: vcom -93 -quiet -nologo -work mingzi_lib/modelsim mingzi_lib/mingzi_lib.vhd
** Error: mingzi_lib/mingzi_lib.vhd(13): (vcom-1136) Unknown identifier "fsvec_2_int32".
** Note: mingzi_lib/mingzi_lib.vhd(187): VHDL Compiler exiting
*** Exception: VHDL Compilation Error: Modelsim failed
in system definition `mingzi' (created in <unkown>)
CallStack (from HasCallStack):
error, called at src/ForSyDe/Deep/ForSyDeErr.hs:461:18 in forsyde-deep-0.2.0-7deUbX6BizeCKOZ9sbSqT7:ForSyDe.Deep.ForSyDeErr
*Take> writeVHDL takeSysDef
*Take> writeAndModelsimVHDL Nothing takeSysDef [y1]
Running: vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim
Model Technology ModelSim - Intel FPGA Edition vmap 2020.1 Lib Mapping Utility 2020.02 Feb 28 2020
vmap forsyde /home/embedded/Downloads/deep/.stack-work/install/x86_64-linux-tinfo6/41f3446f00eaf30900387f62586718ab816bbd89d646a1e0d09fd9d4762383ee/8.0.2/share/x86_64-linux-ghc-8.0.2/forsyde-deep-0.2.0/lib/modelsim
Copying /home/embedded/intelFPGA/20.1/modelsim_ase/linuxaloem/../modelsim.ini to modelsim.ini
Modifying modelsim.ini
Running: vlib mingzi_lib/modelsim
Running: vcom -93 -quiet -nologo -work mingzi_lib/modelsim mingzi_lib/mingzi_lib.vhd
** Error: mingzi_lib/mingzi_lib.vhd(13): (vcom-1136) Unknown identifier "fsvec_2_int32".
** Note: mingzi_lib/mingzi_lib.vhd(187): VHDL Compiler exiting
*** Exception: VHDL Compilation Error: Modelsim failed
in system definition `mingzi' (created in <unkown>)
CallStack (from HasCallStack):
error, called at src/ForSyDe/Deep/ForSyDeErr.hs:461:18 in forsyde-deep-0.2.0-7deUbX6BizeCKOZ9sbSqT7:ForSyDe.Deep.ForSyDeErr
Can you merge all branches into a stable master version?
Prepare the next release of forsyde-deep.
Issue by HWoidt
Thursday Jul 09, 2015 at 12:50 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/8
The cabal file lists some dependencies which are remnants of the Forsyde.Shallow package. They should be removed.
Additionally the package description should be updated.
Issue by HWoidt
Saturday Jul 11, 2015 at 13:00 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/11
Reported by [email protected], Apr 23, 2008
We would like support for subtypes like the one provided by VHDL.
This is something like 'integer range 0 to 5', which is necessary for
efficient hardware designs.
Issue by HWoidt
Thursday Jul 09, 2015 at 12:31 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/4
The function newSysDefTHName does a reify of the Name value that is passed in for the system function.
This reification fails, complaining that the symbol is not in the scope of the current splice.
Issue by HWoidt
Saturday Jul 11, 2015 at 13:04 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/16
Reported by [email protected], Jun 23, 2008
As we know, all the types handled by ForSyDe are required to be instances
of Data.
Creating a "Data a => Lift a" (undecidable) instance would make all
instances of Data (and implicilty all ForSyDe-supported types) also
instances of Lift, sparing us from needing to use $(deriveLift
WhateverDataType).
I created ticket [1] in GHC's track asking for this feature a while ago,
and they accepted to include it in GHC 6.10, but that won't happen in a while.
Issue by HWoidt
Saturday Jul 11, 2015 at 13:05 GMT
Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/18
Reported by [email protected], Aug 9, 2008
The code in src/ForSyDe/Backend/Simulation.hs works but looks terrible, it
should be cleaned up.
Furthermore, it should use ForSyDe.Netlist.Traverse.traverseSEST instead of
ForSyDe.Netlist.traverseST .
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.